New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add initial support for a toolchain based module naming scheme #1168
Conversation
software is installed in a directory specific to each toolchain, and each toolchain module extends the path. This won't work unless toolchains properly inherit (iccifort -> iimpi -> intel) and dependencies are listed appropriately in toolchains. The other required change in easyblock.py changed the order of statements written in the module file so that the 'module use' statement appears after loading the dependencies. This allows the module path to be updated in the correct order in this naming scheme.
Automatic reply from Jenkins: Can I test this? |
Part of the reason for doing this is that, in a hierarchy, |
Jenkins: ok to test |
This is useful when toolchains are not exposed to users. | ||
""" | ||
# return True | ||
# In our case we have to load the toolchains because they are explicitly exposed when extending the module path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indent comment
we would also need to have this tested by the unit tests, to ensure it doesn't get broken by changes in the framework in the future |
Fixed the names...added some humour
Refer to this link for build results (access rights to CI server needed): |
Fixed comments from @boegel
Final deletions
I'll take a look at the tests you mentioned in #1176 and see how this might be done. I'm a little surprised it passed the tests because without modifying intel or goolf to include a dependency on iimpi/gompi (and then iteratively), you almost certainly can't install software within this MNS. It will work for gpsolf and intel-para though because I've already defined them hierarchically. I'll be able to resolve this more completely once we implement the method for subtoolchains, since I can enforce the dependency then (given this MNS is in use). |
The tests pass because they're not using this new MNS.. :-) |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
sync with develop
Refer to this link for build results (access rights to CI server needed): |
@ocaisa: ignore the failing test, Jenkins must be drunk |
Jenkins: test this please |
Refer to this link for build results (access rights to CI server needed): |
We currently still need to expand the toolchain load because of the current lack of support for subtoolchains within the framework
Refer to this link for build results (access rights to CI server needed): |
…develop Conflicts: easybuild/framework/easyblock.py
EasyBuild framework unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-framework-pr-builder/2082/console for more details). This pull request is now ready for review/testing. Please try and find someone who can tackle this; contact @boegel if you're not sure what to do. |
@ocaisa: what's going on with your last commit? I'm not sure how useful an empty pull request is... ;) |
EasyBuild framework unit test suite FAILed. See https://jenkins1.ugent.be/job/easybuild-framework-pr-builder/2085/console for more details. Please fix the reported issues by pushing additional commits to the branch corresponding with this pull request; contact @boegel if you're not sure what to do. |
@ocaisa: last tests have failed due to an issue on Jenkins, I'm looking into it |
Jenkins: test this please |
Argh, I was tidying up everything for the subtoolchain stuff and I deleted the MNS from the branch history to keep things clean...but I never forked the original devel branch so things got complicated. |
@ocaisa: |
EasyBuild framework unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-framework-pr-builder/2090/console for more details). This pull request is now ready for review/testing. Please try and find someone who can tackle this; contact @boegel if you're not sure what to do. |
EasyBuild framework unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-framework-pr-builder/2185/console for more details). This pull request is now ready for review/testing. Please try and find someone who can tackle this; contact @boegel if you're not sure what to do. |
@ocaisa any idea why we ended up not including @bartoldeman was hitting a problem with easybuilders/easybuild-easyconfigs#2899, basically because Do you have an updated version of |
It couldn't work properly because it relied on knowing which toolchain it was inheriting from (you need to have |
Annoyingly I pulled directly from my develop branch so I need to open a new PR from a fresh branch...though the scheme is still effectively broken and will only work with some manual editing of toolchain easyconfigs to add the appropriate subtoolchain dependencies |
@ocaisa I was mainly asking because I was figuring out the bug that got fixed with #1754; if you know it doesn't work (well), there's probably little point in contributing it back? Although, I have to admit, this is a scheme we would consider using, so maybe it is useful to have a PR for it that makes it clear what the known problems are. |
where software is installed in a directory specific to each toolchain, and each toolchain module extends the module path variable.
NB This won't work unless toolchains properly inherit (iccifort -> iimpi ->intel) and/or dependencies are listed appropriately in toolchains.
The other required change in easyblock.py changed the order of statements written in the module file so that the 'module use' statement appears after loading the dependencies. This allows the module path to be updated in the correct order in this naming scheme.