Is it possible to specify the compiler in the fpm.toml?

May be it has already answered but I couldn’t find a it.
Is it possible to specify the compiler to use inside the fpm.toml?
I know that I can use the env variable FPM_FC or pass the --compiler option, but it would be easier if there is a way to put it in the fpm.toml, even though it may not be portable.

I’m writing a program inside wsl2 thatis based on ubuntu. I wanted to include vegetables to add some tests, but the standard gfortran version 9… cannot compile vegetables, so I installed gfortran-10 with sudo apt install gfortran-10.

And works, but now the fortran compiler should be called gfortran-10 instead of gfortran. So I may need to remember to always set the variable FPM_FC or use always --compiler, unless I could put it in the fpm.toml.

By the way I have tried with ifort (just passing --compiler ifort) and didn’t compile as it required a -coarray optional arguments to the compiler as evidently vegetables is declaring some coarray.


1 Like

Unfortunately the answer to your question is no. We’ve been getting more requests for this lately though, so maybe we’ll get around to making a “global settings” file that fpm can read and you can put it there. I.e. something like, put the following in a file $HOME/.local/fpm/settings.toml

default_compiler = gfortran-10

We haven’t done so yet though.

As an aside though, vegetables has been superseded by veggies and garden, garden maintaining the coarray support and veggies dropping it. So if you switch to veggies (it should be just a simple name replacement) you won’t need the coarray option for ifort. I will unfortunately note that I have not had reliable behavior from ifort with several of my libraries, veggies being one of them.


I have found the following errors trying to compile veggies with ifort:

build/dependencies/veggies/src/veggies/result_m.f90(98): error #6764: A unary defined OPERATOR definition is missing or incorrect. [NOT]
allocate(failed, source = .not.self%results%passed())
build/dependencies/veggies/src/veggies/result_m.f90(98): error #8155: In an ALLOCATE statement the source expression in SOURCE= or MOLD= specifiers must be of the same type and kind type parameters as the object being allocated.
allocate(failed, source = .not.self%results%passed())
build/dependencies/veggies/src/veggies/result_m.f90(98): error #8198: If the ALLOCATE object is an array and there is no allocate shape specification, source expression in SOURCE= or MOLD= specifiers must appear with the same rank as the ALLOCATE object. [FAILED]
allocate(failed, source = .not.self%results%passed())

The compiler didn’t like:

allocate(failed, source = .not.self%results%passed())

I substituted it with:

failed = .not.self%results%passed()

That I assume should do the same thing (if I’m wrong tell me so I can learn something).
The compilation was fine, even though when I run the veggies test I had a segmentation fault in:

(gdb) where
#0  0x00000000007ea0f0 in for.calc_num_elts ()
#1  0x00000000007f37f7 in for_finalize ()
#2  0x00000000007f3a80 in for_finalize ()
#3  0x00000000007f3a80 in for_finalize ()
#4  0x00000000007f3a80 in for_finalize ()
#5  0x00000000007f3a80 in for_finalize ()
#6  0x00000000007f3a80 in for_finalize ()
#7  0x000000000068d460 in veggies_test_constructors_m::describe_with_input_c (item=..., description=..., input=0x7fffffff89e8, tests=...,
    .tmp.DESCRIPTION.len_V$2881=23) at ././src/veggies/test_constructors_m.f90:158
#8  0x0000000000694869 in veggies_test_constructors_m::given_with_input_c (item=..., description=..., input=0x7fffffff89e8, tests=...,
    .tmp.DESCRIPTION.len_V$4a95=17) at ././src/veggies/test_constructors_m.f90:286
#9  0x000000000063faba in filter_test::test_filter_collection (tests=...) at test/filter_test.f90:61
#10 0x000000000040b1c9 in main::run () at test/main.f90:135
#11 0x0000000000404a83 in main () at test/main.f90:5
#12 0x0000000000404a1d in main ()

As I told you I’m on a WSL2 Ubuntu.

Although you currently cannot create your own profile in the fpm.toml file you can create a
response file in the root of the project and create abbreviations. They can get more complicated
but for example, name the file “fpm.rsp”

# note quotes are generally required on options, must use optional
# argument keys like --target
option run --compiler gfortran-10 --verbose --profile release
option test --compiler gfortran-10 --verbose --profile release
option build --compiler gfortran-10 --verbose --profile release

and then you can enter commands like

fpm @test
fpm @run --target prog1
fpm @build

as described in the M_CLI2 documentation.]

Typically, you rename the gfortran link to point to your latest version. This is often done by the
install scripts, but sometimes you need to do this manually.


Yes, that is an equivalent statement. Haven’t really had a chance to explore why ifort doesn’t like the original.

Yep, the behavior of veggies under ifort is unpredictable. Running different subsets of the test suite will sometimes work and sometimes crash. It has to do with ifort not properly deallocating recursive, polymorphic derived types. The handful of times I’ve tried it, things were so borked it segfaulted the debugger. I reported a simpler example that used to reproduce the behavior (I even made a YouTube video about it), and newer versions can run that example, but still not veggies test suites reliably. I’m hopeful that the new ifx will be able to work with my libraries soon.

I updated WSL to ubuntu 22.04 that has gfortran 11 and now veggies compile and run all tests without error.


The response file can be used in the command line in the terminal, however, it seems that the filename must be build.rsp to be able to execute “fpm @build” and others similarly. Is this correct?

If I name the file fpm.rsp, I get the following error message:
response name [@build] not found

Thanks in advance for your comments!

Based on the M_CLI2 documentation, it is possible to have a compound response file whose name should be EXEC.rsp where EXEC is the name of the executable. When using a response file in a package using FPM for its compilation, the EXEC is indeed the name of the FPM binary not the executable of the package. There are a couple of packages on github with the response file named fpm.rsp, this means the name of the binary of FPM must be fpm or a soft link whose name is fpm.
Those, who download the binary of FPM from github, should pay attention to this point.