ICON Subclassing without parsing configure args

[leclairm]

In order to make extending the ICON package recipe easier, we suggest the following:

• Store the variants to be en-or-disabled in the EN_DIS_ABLE_FLAGS class variable.
• Create 3 new attributes, single_args, flags and config_libs to host configure args.
• Populate them in the new set_configure_args method.
• configure_args becomes a small method that concatenate the content of these 3 attributes in the final list[str].

Doing this would greatly improve the subclassing experience of the ICON package recipe like it is done here where parsing of the configure args is necessary. With this PR, we could modify self.single_args and self.flags where we need, e.g. with

    def set_configure_args(self) -> None:
        super().set_configure_args()
        # Modify self.single_args, self.flags and self.config_libs

or

    @run_before("configure")
    def extend_configure_args(self) -> None:
        # Modify self.single_args, self.flags and self.config_libs

Also extending EN_DIS_ABLE_FLAGS would help by keeping the logic in the parent class.

[Try2Code]

hi!
I hope u realize that any spack package will always lag behind the icon building - by definition.

but a little off-topic question: why is a subclass of icon actually needed? I was not aware of it

[leclairm]

Hi!

hi! I hope u realize that any spack package will always lag behind the icon building - by definition.

Of course I do. I don't get why that question?

but a little off-topic question: why is a subclass of icon actually needed? I was not aware of it

Ah, I didn't know this wasn't known! We rely on a subclass at MCH and C2SM since years where we put different variants or behaviours not necessarily suitable for upstreaming. Also for being able to quickly give access to a feature if necessary. Now that ICON is open source, we can probably upstream quite a bit of these to the main ICON recipe. I was hoping to do that in a second stage.