Fpm: profiles and file-dependent flags

Help fpm
1

Hello, I have a few questions regarding the use of fpm. I feel they are all simple questions, but I am somehow stuck. Here it goes:

  1. Is it possible to redefine and/or extend the default release and debug profiles by editing the fpm.toml file? (I know we can do it on the command line with the --flag option, but that is not the question).
  2. Is it possible to define custom profiles in the fpm.toml file?
  3. Suppose I have code in modern Fortran that “uses” an F77 library which can only be compiled with the -std=legacy flag. How do I tell fpm to use the -std=legacy for the legacy code, but not for the rest?
1 Like
2

I don’t think it’s possible yet, but you can use response file to define flags to extend release and debug profiles.
I’m not sure where the docs for response files are for fpm, but I think they come from M_CLI2 which gives the specification here.

I’ve used response files here to debug different builds (with and without openmp).
Hope this helps

4 Likes
3

Woah, this seems to be a million-dollar catch!

4

The short answer is not yet. There was a prototype implementation for all 3 aspects last summer as a Google Summer of Code project. Unfortunately there were a couple of aspects that deserved some rework and it was not merged.

If you’d like to provide any assistance finishing it, we’ve already finished up the ability to specify the profiles in the fpm.toml file (Enable profiles in toml by kubajj · Pull Request #653 · fortran-lang/fpm · GitHub). It needs to be worked out how to get the right flags to the compiler for each specific source file. The original work was done in Compiler flags profiles by kubajj · Pull Request #498 · fortran-lang/fpm · GitHub and Add parent packages into dependency tree by kubajj · Pull Request #539 · fortran-lang/fpm · GitHub

I’d be happy to help anybody willing to pick the effort back up.

5 Likes
5

Thanks, a lot for the clear explanation. I saw this slide set fortran-lang-purple Handling Compiler Flags in fpm - fortran-lang-purple FortranCon 2021 (uzh.ch) a few weeks ago. Naively, I tried editing the fpm.toml file according to the instructions, but it did not work! Now, I know why! :slight_smile:

2 Likes
6

Is there a reason for not this first part being bounded to all the rest? Couldn’t it be already available for users while the rest is being worked out? (well, maybe you cannot ensure for now that the API would remain untouched after thinking through the whole matter, I would understand that…)

7

The issue was in the internal implementation. The definition of the profiles in the fpm.toml was well designed, and not particularly controversial, so separating that part out and going ahead with implementing it was easy enough. It would not have been a good idea to merge in the undesirable implementation for the internal workings. That would have meant it was in the way of other feature development, and possibly have been harder to undo later.

2 Likes
8

Real world case

Hi, reviving the post to ask for support defining file-dependent compile flags via response files, if possible.

I want to make SciFortran[1] build (and even more importantly run a testsuite) via fpm as soon as possible. The long term goal would be to fpm-ize all the downstream condensed matter libraries we have and eventually just have a fpm.toml manifest for each single research project.
With respect to our current CMake build system (which is very functional as far as build and installation are concerned), I see the huge advantage of an exact version management of all the needed libraries: currently each driver program depends on SciFortran, DMFT-tools and usually another techinique-specific “solver” library (DMFT, Slave-Spins, Exact Diagonalization, etc…), so that a manual version management of each combination is quite a nightmare.
Basically in the research group people either update everything constantly (what I do), potentially dealing with annoying regressions if they manage their way to a git tag (it happens…) or totally freeze the whole environment, tipically for years (that is normally done by people doing “applied research” with long established “options”, I could never do that as I’m developing extensions to our solver libraries). I truly think fpm would drastically improve each one’s workflow and alleviate tremendously collaborations.

For SciFortran, currently, I believe the only one crucial thing I am missing is exactly support for file-dependent compilation flags, similarly to OP in that we have many legacy files here and there. The situation is quite pervasive, but just to give an example

minimize_krauth.f is a fixed-form external procedure, that is being called within a modern interface. The main pain point for fpm is that this procedure actually uses an implicit mapping together with several deprecated/removed legacy features, so it won’t compile with our debug profile (for gfortran: -O0 -p -g -fimplicit-none -Wsurprising -Waliasing -fwhole-file -fcheck=all -pedantic -fbacktrace -ffree-line-length-none).

In the CMake configuration we just define a weaker set of flags just for the legacy files, any idea on how to tackle this with an appropriate response file? Also, would it work when listing SciFortran as an fpm-dependency for another library? (i.e. can I make fpm call the custom response profile, instead of the default build?).

This would already go a long long way…

  1. GitHub - QcmPlab/SciFortran: A library of fortran modules and routines for scientific calculations (*in a way* just like scipy for python) ↩︎

9

The response files are processed at the time the fpm(1) command is executed, not when the file is compiled (it is a feature for any program that parses using the M_CLI2 module; which knows nothing about fpm(1) per-se).

Until the project to add just that capability to fpm (mentioned previously) the only thing that comes to mind is a wrapper around the compiler command that reads from a file of options or uses Cmake or make
for the compilation, which seems to be too complicated a path.

But right now to use the response files would require placing each set of files that requires different options into separate projects; and then there is the problem of using those options for dependency builds; which would probably mean using them as external dependencies built in a common shared area
which would not force a particular build method for any particular dependency.

It seems adding that option to fpm(1) really is critical to go forward and at the same time keep everything simple at the user level.

The response file option was inspired by issues with fpm(1) usage, but basically is a way to abbreviate long fpm(1) commands; not part of the fpm build machine though.

3 Likes