Thanks @Carltoffel , these are valid points related to the above. We have separate issues tracking these (linked below) where you can see some possible solutions or propose your own if you have any ideas!
See here also for how fpm already has basic support for MPI with the Intel mpiifort wrapper.
opened 06:30PM - 09 Feb 21 UTC
specification
Many Fortran codes use MPI and we should teach `fpm` about it and support it nat… ively.
There are two main approaches to it:
* Use the mpi compiler wrappers such as `mpif90`, which are provided by MPI implementations such as `mpich` or `openmpi`. Those compiler wrappers call the compiler with correct flags to link all MPI libraries correctly.
* You call the compiler wrappers `mpif90` to figure out what flags to use, then you supply those flags manually when executing the given compiler.
CMake supports both options and I have used both in my projects. There are pros and cons of each approach and I have discussed this with quite a lot of people already. I personally lean towards the second approach, which treats MPI as a 3rd party library that you depend on. Ultimately, that is what it is. However, for `fpm`, the user does not actually see how the compiler is being invoked anyway, so the first approach might also work. So I would choose whatever approach is easier to implement and maintain in fpm and I think we can even switch later (internally) if needed.
Let's discuss the user facing design. It seems it might be as simple as adding `mpi=true` into `fpm.toml` for each executable that should be compiled with MPI. And `fpm` would then transitively enable MPI for each module and dependency that the executable needs. In terms of choosing which MPI implementation should be used, we can start by using whatever `mpif90` is available in `PATH`.
opened 08:32PM - 12 Apr 21 UTC
This is a whole can of worms. The documentation regarding the [`dependency()`](h… ttps://mesonbuild.com/Dependencies.html) function in meson gives a nice impression on all the things one can / has to consider when dealing with dependencies.
*How does fpm find dependencies now?*
Currently, we assume the compiler can find external libraries and include files all by itself.
This works fine for system libraries, but usually there are packages under different prefixes like `/opt` or in the users home which could also be used, but are not included by default.
*Using a dependency tool*
A somewhat standard way to handle non-system dependencies are `pkg-config` or `cmake` package files, some platforms might provide their own like OSX frameworks. Also some packages are known to provide incorrect package files.
*Using environment variables*
An third-party library usually provides a way to make itself known to the system, using environment variables like `CPATH` to add include directories, `LIBRARY_PATH` to add to the library search path and `LD_LIBRARY_PATH` to add to the runtime load path. This mechanism allows fpm to automatically pick up third-party dependencies by relying on the compiler.
*Setup scripts / environment modules*
Setting those variables in the first place is tricky, usually third-party libraries provide scripts which can be sourced by the shell or an environment module that can be loaded. Sometimes those scripts and modules are not working correctly as well. This is a common issue with environment modules which miss certain crucial environment variables (missing `CMAKE_PREFIX_PATH` is a classic).
---
As a developer there is nothing more painful than working in a broken environment. Either because some overzealous setup script in `/etc/profile.d` messes with all other packages, an environment module exports the wrong paths, or a `pc` file with a typo won't be recognized.
*Can we / Should we do something about this?*