# Fpm: profiles and file-dependent flags **URL:** \ **Category:** fpm\ **Created:** [September 30, 2022, 6:09pm UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437 "2022-09-30T18:09:23Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![HugoMVale](https://avatars.discourse-cdn.com/v4/letter/h/e19adc/32.png) [@HugoMVale](https://fortran-lang.discourse.group/u/HugoMVale)\ **Post date:** [September 30, 2022, 6:09pm UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/1 "2022-09-30T18:09:23Z")
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? ---
**Author:** ![lewisfish](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/lewisfish/32/1132_2.png) [@lewisfish](https://fortran-lang.discourse.group/u/lewisfish)\ **Post date:** [September 30, 2022, 8:27pm UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/2 "2022-09-30T20:27:47Z")
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](https://urbanjost.github.io/M_CLI2/set_args.3m_cli2.html#8). I’ve used response files [here](https://github.com/lewisfish/signedMCRT/blob/main/fpm.rsp) to debug different builds (with and without openmp). Hope this helps ---
**Author:** ![rgba](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/rgba/32/2115_2.png) [@rgba](https://fortran-lang.discourse.group/u/rgba)\ **Post date:** [October 1, 2022, 3:48pm UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/3 "2022-10-01T15:48:46Z")
Woah, this seems to be a million-dollar catch! ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [October 2, 2022, 9:49pm UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/4 "2022-10-02T21:49:46Z")
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](https://github.com/fortran-lang/fpm/pull/653)). 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](https://github.com/fortran-lang/fpm/pull/498) and [Add parent packages into dependency tree by kubajj · Pull Request #539 · fortran-lang/fpm · GitHub](https://github.com/fortran-lang/fpm/pull/539) I’d be happy to help anybody willing to pick the effort back up. ---
**Author:** ![HugoMVale](https://avatars.discourse-cdn.com/v4/letter/h/e19adc/32.png) [@HugoMVale](https://fortran-lang.discourse.group/u/HugoMVale)\ **Post date:** [October 3, 2022, 7:32am UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/5 "2022-10-03T07:32:25Z")
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)](https://tcevents.chem.uzh.ch/event/14/contributions/66/attachments/63/142/Hanling_compiler_flags_in_fpm.pdf) 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! 🙂 ---
**Author:** ![rgba](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/rgba/32/2115_2.png) [@rgba](https://fortran-lang.discourse.group/u/rgba)\ **Post date:** [October 4, 2022, 10:08pm UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/6 "2022-10-04T22:08:47Z")
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…) ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [October 5, 2022, 1:05am UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/7 "2022-10-05T01:05:02Z")
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. ---
**Author:** ![rgba](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/rgba/32/2115_2.png) [@rgba](https://fortran-lang.discourse.group/u/rgba)\ **Post date:** [October 16, 2022, 11:58am UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/8 "2022-10-16T11:58:06Z")
## 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](https://github.com/QcmPlab/SciFortran/blob/master/src/SF_OPTIMIZE/minimize_krauth.f) is a fixed-form external procedure, that is being called within a [modern interface](https://github.com/QcmPlab/SciFortran/blob/master/src/SF_OPTIMIZE/fmin_cg_minimize.f90). The main pain point for `fpm` is that this procedure actually uses an [implicit mapping](https://github.com/QcmPlab/SciFortran/blob/57d16a1b8dfa8aa107a6152980bb326038025164/src/SF_OPTIMIZE/minimize_krauth.f#L11) 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: Archived. Development moved elsewhere (see link below).](https://github.com/QcmPlab/SciFortran) ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [October 16, 2022, 5:39pm UTC](https://fortran-lang.discourse.group/t/fpm-profiles-and-file-dependent-flags/4437/9 "2022-10-16T17:39:38Z")
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.