WIP: Fortran dialects default FLAGS and PATH if not set

[mwichmann]

The manpage has always said that for a given dialect (e.g. F90), you should set FORTRANFLAGS and FORTRANPATH unless you need values that are unique to just that dialect, in which case you can set the dialect-specific ones (e.g. F90FLAGS and/or F90PATH). However, the implementation never actually picked up the generic settings if the dialect-specific settings were not given. This change now picks up the defaults if the dialect does not have a value set.

Manpage section on Fortran dialects is reworded for greater clarity.

Fixes #4686

Contributor Checklist:

• I have created a new test or updated the unit tests to cover the new/changed functionality.
• I have updated CHANGES.txt and RELEASE.txt (and read the README.rst).
• I have updated the appropriate documentation

[mwichmann]

Hmmm, fails some tests on Windows:

        test\Fortran\SHF77FLAGS.py
	test\Fortran\SHF90FLAGS.py
	test\Fortran\SHF95FLAGS.py

Will investigate.

Update: this may be a previously unexploited hole in a stub tool used by the test, since this is a flag-handling test that doesn't need a real compiler - myfortran_flags.py.

[mwichmann]

Nope, wasn't a fault of the tool, but a side effect of defaulting to an un-substituted string and then the tests doing Append on that string. The Append implementation preserves a scalar string as a string, while it correctly adds to a list in a string. We normally use CLVar for this for flags intended for the command line, so updated to do so here as well. It remains unclear why this didn't trip on Linux, where my tests (and those of CI) still passed. There's still an issue here... will keep investigating.

[mwichmann]

Let's try to summarize where things are now:

For FLAGS variables, the manpage says FORTRANFLAGS is used for all dialects. This is not true - it's ignored for all the dialects not named FORTRAN. However, the recently added FORTRANCOMMONFLAGS is, and I propose updating the manpage to change this reference.

If a flags cvar is defaulted to FORTRANFLAGS, it can be done in two ways: as the SCons-y '$FORTRANFLAGS', which will pick up any changes later to FORTRANFLAGS, or as a snapshot of the current value (essentially, env['FORTRANFLAGS']), which will not pick up later changes. Two current tests, the shared-object tests for F90 anf F95 dialects, break on the former approach, because they don't expect FORTRANFLAGS to be tracked in this case:

env.Append(SHF90FLAGS='-x', SHFORTRANFLAGS='-y')

And then count on only -x being set in the flags passed to the (mock) compiler. If you default unset $SHF90FLAGS to $FORTRANFLAGS, then after appending, the former will become ['$FORTRANFLAGS', '-x'] and the latter ['-y']so that the eventual substituted result becomes['-y', '-x']. Of course, one could update those tests to expect both. The snapshot form avoids that problem: appending to whatever was in $FORTRANFLAGShas a different result than appending to a string $FORTRANFLAGS(actually aCLVar` containing the string), which will be further expanded later. But if you did pick up the common flags, shouldn't you actually be tracking them as they evolve?

I don't see a good way to resolve that - you can argue several different approaches as the "right" behavior in the face of the possibility of changes after the possible defaulting takes place, which happens at tool setup time. Not just appending, but overrides. So I think it's better to forget about it and just rewrite docs so FORTRANCOMMONFLAGS is the fallback - which is already is in implementation, as it's expanded as part of the dialectCOM variable, like: ... $FORTRANCOMMONFLAGS ${dialect}FLAGS $_{dialect}INCFLAGS .... That behavior is unambiguous.

---

For the PATH variables, the story is a little different. These are for telling the compiler where to look for headers, and also to tell the scanner where to look. There's no corresponding FORTRANCOMMONPATH, and again the manpage tells you to set FORTRANPATH unless you need a dialect-specific search path - but search paths are typically more project-oriented, and although it could happen, I have trouble of thinking of a case where you need to specify a path to something that only applies to files suffixed (for example) .F95. Header file search paths are typically additive anyway, so it feels like the dialect-PATH ought to also include the contents of FORTRANPATH, rather than default to FORTRANPATH only if the dialect one has no value. In thinking about paths, we now also have the more recently added FORTRANMODDIR - the path to place (and thus, to find) generated module description files. That one has no corresponding dialect-specific versions, to make things even less consistent.

[mwichmann]

@bdbaddog pushed a revision to the f90 dialect docs - this reflects the proposal to describe FORTRANCOMMONFLAGS rather than FORTRANFLAGS as the variable to set for generic options. Also does a fair bit of cleanup and removes one rather glaring error (used to wrongly say F90FLAGS is processed by _F90INCFLAGS, which, of course, acts on F90PATHS instead). Would appreciate a review of this approach before spending the time to similarly update the other four dialect doc files - it's a non-trivial amount of fiddling, although not complicated or a huge overhaul.