Package options in fpm.toml

[awvwgk]

Came up in #190 and disabling/enabling the auto discovery features.

Generally, we need a way to customize fpm per package, as a first suggestion for the auto discovery:

[build]  # or config, ...
auto-executables = true
auto-tests = false

The fpm-options could include other information as well, like

[build]
fast-math = false  # don't use -ffast-math
standard = "2008"
preprocessor = "fypp"

There are two major questions here

1. Which table should hold options to customize fpm per package?
   • manifest root, [build], [config], ...
2. Which options do want to include in this section?
   • auto-discovery, standard, preprocessor, compiler flags, ...

[LKedward]

I prefer [build] over [config] as the table name since it's more descriptive. We could also include an option to turn-on link-time optimization (LTO). I'm not sure about preprocessor as a global option - I'd assumed that we'd be able to determine if a source needs a particular preprocessor based on file extension? This would allow both fypp and cpp to be used in the same project.

For compiler/linker flags it would be useful to have two options for either appending to or overriding built-in flags, e.g.:

fflags-extra       # Append to fortran compiler flags
fflags             # Override fortran compiler flags
cflags               
cflags-extra
lflags
lflags-extra

[awvwgk]

I'd assumed that we'd be able to determine if a source needs a particular preprocessor based on file extension?

The relevant issue should be #78 for this discussion. The conclusion seems to be that supporting both is necessary. I think fypp and cpp should be mutually exclusive on per project basis, since both would probably use .F90 as file extension. We could search for .fypp macro files, but a project can use fypp without defining those.

I think, we have yet to establish a best practise on preprocessor usage with fpm.

[everythingfunctional]

I think this will almost certainly be necessary, and I like [build] as the table. I think each option/entry in the table will need it's own discussion, but one thing I think each will need to answer is: How are the precedence or combinations of options handled during the building of dependencies?

As an example (and I'm certain there will be others for which the answer may be different), if a package specifies fast-math = false, but it has a dependency that specifies fast-math = true, is that dependency built with or without fast math? Presumably that dependency isn't doing anything for which fast math would cause issues, and it would still be safe to compile it with fast math, and compile the main package without. But then what about the reverse scenario? Is that still safe?

But we should probably just save those discussions for each specific option.

[certik]

Depending on what exactly ends up in [build], the other option to use is [package] or [fpm]. I think [build] is fine for stuff like compiler options or fast-math. For auto discovery my first inclination was to use a section [fpm]. But [build] is fine with me also, so let's go with that.

I think fast-math is tricky, I think one approach is:

• there is a flag that specifies if a given package works with fast math. We can discuss if this flag should be on by default, the safe is off by default. This flag can be called fast-math. This is the only flag that you specify in fpm.toml.

• When the user uses fpm to build an app, it can specify options on the command line such as fast-math. By default this fast-math option can be on. If this option is on, fpm will check all dependencies, and if they all have their fast-math flag on, it will build everything with fast-math. If even one of them has this flag off, it will build everything with fast-math off. This is the safest approach that will work.

More advanced approach is to mix and match fast-math in dependencies, and my experience is that it doesn't always work, because fast-math enables various CPU hardware options (such as disabling denormal numbers) which screws things up for code that does not work with fast-math. As such, I would recommend the safe approach above.