Installing and including already-installed libraries

[jphaupt]

Hi! I'm still new to Fortran but stumbled upon this project, so sorry if my question is ignorant. My first impression was that it would basically be to Fortran what REPL is to Julia or pip to Python. What I found instead seems to be a (very good) alternative to (c)make. However, I am still quite confused by the install command. Does this just copy an executable to ~/.local/bin (making the program easier to run from anywhere)? Is it outside the scope of fpm, or can I use fpm to install, e.g. stdlib (which, by the way, has instructions on how to build with make and cmake but not fpm)? I was expecting a workflow something akin to

git clone https://github.com/fortran-lang/stdlib
cd stdlib
fpm build --profile release
fpm install

and then in a new project I can simply import stdlib as expected, e.g. from the docs

program demo_open
    use stdlib_io, only: open
    implicit none
    integer :: u
    u = open('example.dat', 'wt')
    write(u,'(a)')'This is an example for open'
    close(u)
end program demo_open

though I don't know if fpm would need some kind of include/link for stdlib then. Is this sort of thing handled by fpm? If so, how would I go about installing and using libraries (like stdlib)? Otherwise, is there a way for fpm to "find" stdlib as cmake would do, to include already-installed packages (that may have been built by e.g. cmake)?

[milancurcic]

Welcome @jphaupt, I'm happy you found fpm.

Stdlib is not yet an fpm package, but we're working on it. Until it is, you can use the up-to-date mirror that @LKedward maintains: https://github.com/LKedward/stdlib-fpm. This describes how to add it as a dependency to your fpm package.

To learn how to add dependencies in general, see this section of the packaging guide (maybe outdated in a few places, let us know if something doesn't work), and this section of the manifest reference.

You can browse all fpm packages that are in registry here: https://fortran-lang.org/packages/fpm.

I look forward to hear how it goes.

[jphaupt]

Thanks for the swift reply! By "an fpm package", do you just mean a package built with fpm?

It looks like the snippet

[dependencies]
stdlib = { git = "https://github.com/LKedward/stdlib-fpm.git" }

simply builds in the current project. While this is great most of the time, I am also wondering about projects already installed (for example, if stdlib one day becomes as commonplace as e.g. C stdlib, then it is likely that most users will have it and many projects would use it and it seems unnecessary that every project have its own copy). It looks to me the options then are to put in an absolute directory (bad idea for other users) or to copy/build in the current project. Is there no way to have stdlib (or stdlib-fpm) installed elsewhere, through fpm, and fpm knowing where to find it (for any system)? I am thinking how any Python programmer could do pip install numpy and then write a program using numpy anywhere in their computer without rebuilding numpy in that directory.

Also, using stdlib-fpm, I still have not used the install command; when is this used?

Edit: Sorry, I didn't realise I posted this as a reply to myself, instead of a reply to the first response.

[awvwgk]

The install.library = true gives you something to work with from outside of fpm, e.g. in make or CMake, using it again in another fpm project kinda defeats its purpose IMO.

The something you get is currently everything fpm has available, all module files, including those of the dependencies and a static library contain the object files of the current library and all its dependencies. Not pretty but makes sure it is at least usable outside of fpm.

[jphaupt]

I'm not sure I understand. I'm interested in possibly building an fpm package which depends on non-fpm packages (for example, stdlib, which I've built with CMake), and/or fpm packages that are built elsewhere in my system. From this discussion, it looks like I can only point to them with path = ... which doesn't necessarily translate well if I am trying to share my code (and is just a bit more arduous but certainly still better than make).

[milancurcic]

Okay, for stdlib, I suggest just using stdlib-fpm as an fpm dependency. It's easier than using stdlib as an external (non-fpm) dependency.

For non-fpm dependencies (like stdlib installed with CMake), here's the current recommended approach. I'll use stdlib as an example.

Add this to your fpm.toml:

[build]
external-modules = ["stdlib_strings", "stdlib_stats"] # add any other modules that you need
link = "fortran_stdlib" # for multiple libs, use the list syntax like in external-modules

and build like this:

LIBRARY_PATH=/path/to/stdlib/install/lib fpm build --flag "-I/path/to/stdlib/install/modules"

Setting the LIBRARY_PATH variable is needed so that the linker knows where to find libfortran_stdlib.a. The -I flag is needed so that the compiler knows where to find the modules.

Alternatively, you can place any external .mod files that you need in the local include/ directory in your project path. Then, fpm will find these automatically and you don't need to specify the -I flag on the command line. This approach is not recommended though, and be careful not to commit external .mod files to your source repo, as they're not portable.

[LKedward]

Hi @jphaupt and welcome!

it seems unnecessary that every project have its own copy ... any Python programmer could do pip install numpy and then write a program using numpy anywhere in their computer without rebuilding numpy in that directory.

It's worth addressing your query about installing dependencies globally versus building them on a per-project basis. The reason that fpm and many modern package managers build/install dependencies on a per-project basis is to avoid problems with conflicting package versions and to support better reproducibility. i.e. to avoid your project later failing because a dependency changed or because you're running on a different machine. Since you mention pip in your example, you are perhaps familiar with Python virtual environments which is the post-hoc Python solution to this problem.

When it comes to Fortran, there are further problems with trying to use globally-installed packages due to incompatibilities between different compilers and compiler versions. It is for these reasons that using installed non-fpm packages in fpm is not particularly easy currently as demonstrated above.

[jphaupt]

Yes, admittedly most of my programming experience is in "higher-level" languages like Python and Haskell. I appreciate the (very fast!) help. I shall stick to rebuilding the fpm module each time and using explicit include paths when necessary at least for now. I suppose part of my confusion is also that common packages like lapack and blas do not need to be rebuilt/installed for some reason, but I understand these are special somehow.
(I have marked the other response as the answer)