Skip to content

lmod: module files are written in a root folder named by target family#13121

Merged
tgamblin merged 2 commits intospack:developfrom
alalazo:fixes/lmod_and_microarchitectures
Oct 15, 2019
Merged

lmod: module files are written in a root folder named by target family#13121
tgamblin merged 2 commits intospack:developfrom
alalazo:fixes/lmod_and_microarchitectures

Conversation

@alalazo
Copy link
Copy Markdown
Member

@alalazo alalazo commented Oct 10, 2019

fixes #13005

This commit fixes an issue with the name of the root directory for module file hierarchies.

Since #3206 the root folder was named after the microarchitecture used for the spec, which is too specific and not backward compatible for lmod hierarchies. Here we compute the root folder name using the target family instead of the target name itself and we add target information in the "whatis" portion of the module file.

fixes spack#13005

This commit fixes an issue with the name of the root directory for
module file hierarchies. Since spack#3206 the root folder was named after
the microarchitecture used for the spec, which is too specific and
not backward compatible for lmod hierarchies. Here we compute the
root folder name using the target family instead of the target name
itself and we add target information in the 'whatis' portion of the
module file.
@alalazo
Copy link
Copy Markdown
Member Author

alalazo commented Oct 10, 2019

@hartzell @odoublewen After thinking a bit about the issue, this seems to me the best fix at hand. It should be backward compatible for the naming of the folders and will cover most of the cases. Let me know if this solves your problem and what do you think of the PR.

@odoublewen
Copy link
Copy Markdown
Contributor

I tried this out and it works for me. The lmod Core directory winds up in spack/share/spack/lmod/linux-centos7-x86_64/Core, even when I don't specify target: x86_64 in packages.yaml.

Thank you @alalazo

@hartzell
Copy link
Copy Markdown
Contributor

@odoublewen -- when you load that Core module, does it "unlock" all of the %[email protected] applications that you've built (in other words, do it add The Right Thing(tm) to MODULEPATH?)?

@odoublewen
Copy link
Copy Markdown
Contributor

Yes, everything works correctly. Tested both with simple standalone modules and modules that have complex runtime dependencies (looking at you python). I also tested it manually, outside of our CI job, and yes, after I (1) source the lmod bash script, (2) module use spack/share/spack/lmod/linux-centos7-x86_64/Core, and (3) module load [email protected], I have access to all of the modules built with gcc 8.2.0. The lmod modules Do The Right Thing.

@hartzell
Copy link
Copy Markdown
Contributor

The lmod modules Do The Right Thing.

Woo hoo! Thanks @alalazo !

Copy link
Copy Markdown
Contributor

@hartzell hartzell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Copy Markdown
Contributor

@tldahlgren tldahlgren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not an expert in this area of Spack but, with 100% coverage and tests passing for me, it LGTM.

@tgamblin
Copy link
Copy Markdown
Member

@CamStan: does this fix your issue?

@CamStan
Copy link
Copy Markdown
Contributor

CamStan commented Oct 14, 2019

@tgamblin, might have tagged the wrong Cameron.

@tgamblin tgamblin merged commit d33b0ff into spack:develop Oct 15, 2019
@alalazo alalazo deleted the fixes/lmod_and_microarchitectures branch October 16, 2019 05:52
jrmadsen pushed a commit to jrmadsen/spack that referenced this pull request Oct 30, 2019
spack#13121)

fixes spack#13005

This commit fixes an issue with the name of the root directory for
module file hierarchies. Since spack#3206 the root folder was named after
the microarchitecture used for the spec, which is too specific and
not backward compatible for lmod hierarchies. Here we compute the
root folder name using the target family instead of the target name
itself and we add target information in the 'whatis' portion of the
module file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix Something wasn't working, here's a fix modules

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Problems with Lmod modulefile names post-PR#3206

6 participants