Conversation
…how an environment variable is set; also fixed an issue in Spec.dag_hash where the cached dag_hash was potentially truncated
…pec and merge all relevant specs. this means that merged modules are only created based on installed specs.
…he merged specs. currently this doesnt quite work given the way that naming substitutions are performed since they expect details that may not always be in the query spec (even if they dont use them)
…ed to override TclModule.module_specific_content. in particular this function no longer automatically collects a pre-defined set of details (regardless of whether they are used) e.g. the version, compiler, etc. That being said MergedTclModule may want to define its own version of naming_scheme and conflict_scheme (since non-merged tcl modules could be more detailed).
…vironment (using env())
|
Hi Peter. Thanks for working on this. I'll check it out today and let you know about this. As for PE_PRODUCT_LIST, I'm not sure what we use that for. Seems we have a lot of cryptic variables in our module files :/ |
|
@scheibelp Sorry it took me awhile to check this out. Got a chance to take a look at this and play around with it. Would it be difficult to have this automatically done after a compilation is finished? I think a lot of the consultants here would very much like it if they didn't have to run a command after an installation is finished. My guess is they will probably compile for gcc, intel and craype. So rather than have to run a command after compiling the same package with different compilers and PrgEnvs, it would be nice if Spack was able to look through the modules directory find the package name and then maybe create a new merged file while deleting the old one. It looks good in generating the module file however, I found this bug while running
Am I suppose to use spack module for these? Again thanks so much for your help. |
…nstraints); MergedTclModule now gathers properties common to a set of merged specs when constructing a spec that is used for generating names/paths; if no output option is specified for merged_tcl command the module is written to the common module file location
I'm guessing this failed because there isn't an environment variable called "compiler" in your environment. I think you'd want the modules.yaml file to look like:
That should be readily doable. I presume you'd also want to customize where these module files are placed (i.e. so they are placed in the correct location automatically). I think I'd have to add a bit for that but that should also be simple. |
|
@scheibelp I assigned this to myself just to have it pinned somewhere in my issues. |
|
@scheibelp @mamelara Is something like this still desirable? If so I can have a look how to implement it with the current template based system. |
|
I think so, we are still using our in-house modulefile generator for this. |
|
Is this PR still relevant or can it be closed? |
|
No response, so I'm assuming this PR is stale. Feel free to reopen if this feature is still desired. |
4 participants
@mamelara this can be used to create one module file per package (and more generally it is intended to be helpful for your use case at NERSC). I'm curious if you have feedback/questions. I'm also curious if the PE_PRODUCT_LIST variable at https://www.nersc.gov/assets/modulefile-example.txt is used to track modules for unloading when changing the compiler.
When multiple instances of a package are installed, this provides a
merged_tclcommand which creates a module file that can choose between those instances based on the value of an environment variable.For a modules.yaml file with a TCL section like:
If two instances of bzip are created with gcc 4.4.7 and 4.8.5, the command
spack merged-tcl --output=testmodule bzip2will produce a module file like: