Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Enforce suite #358

Open
hiker opened this issue Nov 26, 2024 · 0 comments
Open

Enforce suite #358

hiker opened this issue Nov 26, 2024 · 0 comments
Labels
BOM Issues copied from the BOM fork

Comments

@hiker
Copy link
Collaborator

hiker commented Nov 26, 2024

The function set_default_suite of the ToolRepository is kind of broken. The current behaviour is: the ToolRepository will put the one tool (and I am just changing this while adding MPI support to put all tools of a suite) to the front, and then when looking for a default tool to look from the beginning of the list.

Problem is, if no tool is available for the default suite, this will silently return a completely different tool (e.g. you request 'intel-classic', and might get 'gfortran'). And at some stage (when compiler flags are added to the corresponding compiler, and not as atm to any compiler), you won't even get a warning about invalid flags anymore, since it will just silently use the compiler-specific flags.

So this function should be renamed (enforce_suite or restrict_to_suite??), and if a special suite has been requested, the get_default_tool function should not return a tool that is not part of that suite.

We should still allow the user to explicitly set (different) compilers in a ToolBox, so we cannot remove non-suite tools from the ToolRepository. Suggested implementation: when a suite is requested, the name is validated (check that we have tools of this suite), stored. And when get_default is called and a suite name has been set, restrict this correspondingly.

@hiker hiker added the BOM Issues copied from the BOM fork label Nov 26, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
BOM Issues copied from the BOM fork
Projects
None yet
Development

No branches or pull requests

1 participant