Implement --flag option in Fortran fpm

[awvwgk]

Currently we relying heavily on the --flag option for Fortran fpm releases. Since a solution for the compiler profiles in the package manifest will probably take more time we should come up with a practical solution in the meantime.

What do we need for this? With M_CLI2 and the existing fnv1a file hashing we could easily produce a similar hash namespacing for the compiler flags as currently provided by Haskell fpm removing the necessity to use Haskell fpm for creating the releases.

Potentially blocked by urbanjost/M_CLI2#8

[LKedward]

See also #235

[LKedward]

Thanks for revisiting this @awvwgk, it would be good to get this sorted to move forward with #253.

Unfortunately I don't like the --flag interface currently in Haskell fpm for two reasons:

1. You must specify separate flags with multiple --flag options
2. There's no way to simply add extra flags to the preset debug and release profiles.

These result in long lines like:

fpm/.github/workflows/CI.yml

Line 36 in 482a52b

RELEASE_FLAGS: --flag --static --flag -g --flag -fbacktrace --flag -O3

just to add --static or --fopenmp to the compiler flags.

I'd like to propose a modified interface for Fortran fpm:

1. --flag can take multiple flags within a quoted argument. e.g. fpm build --flag "-O3 --static"
2. If used in combination with --release or --debug (new flag), then --flag will append the specified flags to the associated presets, otherwise the specified flags will be the only flags passed to the compiler.

[awvwgk]

Option 1 is already implemented with #390, I will have a look into option 2 soon.

[urbanjost]

So, as per previous discussions (#220, #235, ...) showed there are questions about whether the flag should create a separate build/* directory; how the switches apply to building remote dependencies; to rebuilds; whether this should only appear on the build command and require giving it an ID for run and test ; how to support this with "TOML" data in fpm.toml and/or in packaging in some form, and so on. So I think this should be made clear this is a global addition ad-hoc to the command and builds into a build/flag*/ directory; as that would still be useful; but that something using hashes or IDs or profile keywords or reading options from profile.toml or "TOML" comments in the source files or some other method will address packaging the options.

Requiring a profile.toml file seems the least complicated, with the assertion it will be edited by commands. So you could enter:

fpm alias ALIAS_NAME [-create  "LIST_OF_FLAGS" |-delete|-list] [--compiler COMPILER_NAME] 

and this would edit a ".fpmprofile.toml" that has a warning message in it saying "do not edit by hand".

This would give aliases to certain flags. Then you could create an ID from a list of PROFILE_NAMEs

We could populate the file with predefined ALIAS_NAME definitions the first time you build if not present or
via "fpm alias -new|-update-add. You could define an ID switch with something like creating a command called "alias" or "aka":

      # define some alias names
      fpm alias profile -create "-pg"
      fpm alias debug -create "-warn all -g0 -traceback"
      fpm alias mpi  -create 'non-minus-l-switches'  # NOT -llibname.[.a.so] names

       # then you can make an ID from a group of aliases
      fpm ID  MYNAME  profile mpi debug ...  --compiler COMPILER_NAME

and then do a

       build|run|test -ID MYNAME

the ID names "default" and "release" could be special names to be used in lieu of the --default and --release names specified by fpm, and would be treated as the default and release values to use when packaged.

Or one of the eight other options talked about before:> If options were in a .fpmprofile file fpm would not even have to have compiler options hard-coded in, it would just edit the .fpmprofile and make sure there were gfortran_default and gfortran_release names defined.

The default ID used with depend on the value of environment variable FPM_ID if not specified.

The build directory could be hashed from options in ID or just use the ID name. There are pros and cons to both approaches. If implemented fully the --debug and --release switches would be gone, all option combinations would be
from IDs and debug and release would just be names that would be predefined in the ".fpmprofile.toml" file. The new
subcommand could also just predefine a ".fpmprofile.toml" file.

So anyway, since none of the other things have seemed to have gained concensus I could use a --flag switch, and want it to apply to remote dependencies as well myself; but wondering if everyone agrees where that will be built and if it has to be recalled exactly for any rebuilds and needs to be specified on a run|test to run, and so on. Either way, it has to be very clear to the user this is for ad-hoc developer use or to build an application and that other methods will be developed for packaging options in the future(?).

[urbanjost]

PS: As part of an earlier look at ways to reliably specify long command options M_CLI2 has "response files" as suggested by @awvwgk that I implemented a beta version of that is similar in some ways to the .fpmprofile.toml file; urbanjost/M_CLI2#5.

Went other directions with that but it does let you create abbreviations for long commands in a platform-independent manner (I probably need to QA it more for use with subcommands, but I use it with an alpha-alpha version of fpm and am starting to warm up to it, although initially unsatisfied with the lack of standardization of "response files").

Anyone finding they want an easy way to abbreviate long option lists? I think something like --flag "LONG LIST" might make this more desirable?

It lets you set up abbreviation files that can be searched for via an optional environment variable so instead of entering
something like

fpm test test1 --flags "-O3 -Walll -traceback ......" --compiler ifort 

you can set up a response file and just enter

fpm @test1

for instance.