Unify flag handling

[Joerg Henrichs (hiker)]

This is getting reasonable stable, but it's currently blocked by #502 (which I need for kernel extraction in gungho). I will also verify that this works as expected with the UM.

[Joerg Henrichs (hiker)]

This PR adds a set of classes to manage Flags. It allows one FlagList to be used everywhere, which can be a mixture of generic flags (that always apply) and path-specific flags.

I have NOT changed the API of Fab itself, most steps take two flag lists (common flags and path flags). If we agree to change the API all these two arguments can be replaced with a single FlagList.

Internally, the path flags are converted to the new MatchFlags, and all handling internally is with FlagList.

Yaswant Pradhan (@yaswant) , Matthew Hambley (@MatthewHambley) , Pierre Siddall (@Pierre-siddall), Sam Clarke-Green (@t00sa) , Cameron Bateman (@cameronbateman-mo)
Ready for a first review.

I did see the automatic comment that I am not calling the super class - the super class is an abstract class that has no implementation of init, and if I add , I get flake8 errors (this is already commented and closed, but it just got raised again). Let me know what I should do there :)

[Joerg Henrichs (hiker)]

Yaswant Pradhan (@yaswant) , Matthew Hambley (@MatthewHambley) , Pierre Siddall (@Pierre-siddall), Sam Clarke-Green (@t00sa) , Cameron Bateman (@cameronbateman-mo) , this has still not been assigned.

Given the breaking lfric builds atm (ultimately because of a intel compiler bug which can't handle a specific OMP continuation line created by a new transmuation script), I have added a small change to also allow psyclone to have flags added (i.e. I made Psyclone a ToolWithFlags instead of a Tool). This way, a site can simple add any additional PSyclone options (like --backend-disable-indentation) if required.

One question:
ATM, if a ProfileFlag does not have a definition for a given profile (when flags for this profile are requested), it will raise an exception. I wonder if it would be more convenient to just return [] in this case. For example, PSyclone will typically have no profile, so I had to add a try/except clause when querying the flags. I am not sure about the best way:

• strict (the way it is, a caller must make sure the profile mode is actually defined for a tool that uses a ProfileFlag), i.e. the way it is atm
• somewhat relaxed (add an option to get_flags where a user can specify to ignore a missing profile or not
• more relaxed (if a tool has no profile defined at all, just return [])
• totally relaxed (always return [])? Risk here is that a typo in a profile-name (on the user site)

My feeling is that the maintainers here prefer to be as strict as possible, so that's what I implemented. I personally would prefer one of "somewhat relaxed" or "more relaxed" :)

[Sam Clarke-Green (t00sa)]

This makes a lot more sense now that I've been through UM #57. I've added a couple of suggestions inline. I leave it up to you whether you want to accept the suggestion of the automatic code quality tool or not!

[Sam Clarke-Green (t00sa)]

Remove unnecessary whitespace:

Suggested change

	ifx.add_flags(["-stand", "f08"], "base")
	ifx.add_flags(["-stand", "f08"], "base")

[Joerg Henrichs (hiker)]

Done, thanks

[Sam Clarke-Green (t00sa)]

Can you update the functions imported from fab.fab_base.site_specific.default to use setup_script_cray etc as you have in lfric core #246? This should help to minimise confusion over functions vs methods.

[Joerg Henrichs (hiker)]

Sure. I have #544 open to keep track of the changes done during the LFRic and UM reviews, but I am happy to get this done quickly (there are a few more things to do, so I'll leave #544 open till the LFRic and UM PRs are merged, and I get a consistent set of changes in - the setup* stuff seems to be stable now :) )

[Joerg Henrichs (hiker)]

Thanks for the review, Sam Clarke-Green (@t00sa). I've addressed the issues, and brought the PR up to current main. Back to you.

[Joerg Henrichs (hiker)]

This makes a lot more sense now that I've been through UM #57. I've added a couple of suggestions inline.

I am glad to hear that - I was hoping that this will be the case, that once you start using/modifying a build script, things fall into place!