Metapackages

[perazz]

This PR aims to address #853 #161 #855. The first 4 metapackages (OpenMP, stdlib, MPI, minpack) are implemented.
Documentation at fortran-lang/fpm-docs#108.

Usage

Metapackages are supported via a keyword in the manifest's dependencies section like it was suggested in #161:

[dependencies]
openmp="*"

Currently, we only support the wildcard ("*"), meaning "any" versions. In the future, this can be extended with constraints.
example programs are given in example_packages/metapackage_* folders, and they're all run by the new CI.

Implementation status

• openmp
• fortran-lang stdlib
• fortran-lang minpack
• MPI: MacOS/x86_64 + GCC + OpenMPI (via brew or mamba)
• MPI: Windows/x86_64 + MinGW + MSMPI (via msys2)
• MPI: MacOS/x86_64 + GCC + MPICH (via brew or mamba)
• MPI: Linux/x86_64 + GCC + OpenMPI (via apt or mamba)
• MPI: Linux/x86_64 + GCC + MPICH (via apt or mamba)
• MPI: Linux/x86_64 + Intel + IntelMPI (via apt)

Summary

• metapackage_t is a project handler that adds flags, dependencies and features to a package to fit the metapackage requirement(s) without messing up the codebase.
• New CI action meta.yml only runs when metapackages are added/modified
• Specific implementations are currently in fpm_meta.f90 for now, will be moved out to individual files next.

[perazz]

cc: @awvwgk @certik @arteevraina @henilp105 @minhqdao

[perazz]

I've added a metapackage for stdlib. So now we have two:

[build]
openmp = "*"
stdlib = "*"

TBD:
what should happen if a package requires another package with different metapackage requirements? this will be important especially for openmp/mpi/opencl...

E.g., my package has no openmp but one of its dependencies has it. Should we just propagate openmp = "*" all the way up or stop the build saying that openmp should be enabled? I would go for option no. 2, it forces the user to know what they're doing.

[perazz]

Appreciate your help @arteevraina, thank you. I believe all your comments are addressed now.

[perazz]

The Windows build sometimes segfaults in the CI (not on my local machine), so, I'm investigating. I suspect it has to do with the fact that the CI uses the msys shell.

[perazz]

Thank you @arteevraina. If there are no more comments from @minhqdao @henilp105 and the other reviewers, I will merge within a few days.

[perazz]

Ok, looks like it's good enough to merge.

[Carltoffel]

E.g., my package has no openmp but one of its dependencies has it. Should we just propagate openmp = "*" all the way up or stop the build saying that openmp should be enabled?

I guess this is the reason I get Unable to find source for module dependency: "stdlib_logger" because it is used in a dependency and I don't directly use/import stdlib in my project?

[perazz]

Thanks @Carltoffel, good point that I agree it needs to be addressed too. Can I ask you to open a new issue on it for discussion?

[Carltoffel]

Can I ask you to open a new issue on it for discussion?

Of course, you can, but I don't quite get what the topic exactly should be. Do you want to discuss a better error message? Or do you want to have a better discussion on how to handle nested dependencies of metapackages?

[perazz]

Correct - thank you! I mean about handling nested dependencies with metapackages. Maybe having an issue for it will draw more attention/discussion.

[Carltoffel]

When I use the MPI metapackage with use mpi, I also have to use build.external-modules = ["mpi"]. Is this behaviour intended? Otherwise, I get:

 + which mpiexec
/usr/bin/mpiexec
<ERROR> *cmd_run* Targets error: Unable to find source for module dependency: "mpi" used by "app/main.f90"

In the example_packages directory, import mpif.h is used, which circumvents this. Which method is preferred?

[perazz]

@Carltoffel, thank you for testing MPI.
So far there is no checking of MPI Fortran modules as their support is inconsistent across the implementations.
However, this should not prevent the user from using them.
As a first step, I will open a PR to automatically add mpi and mpi_f08 to the list of external modules.