package provides for the dynamic modification of a user’s environment via modulefiles.
| tips-for-code-reuse.rst (modules-5.1.1.tar.bz2) | : | tips-for-code-reuse.rst (modules-5.2.0.tar.bz2) |
|---|
| | |
| skipping to change at line 147 | | skipping to change at line 147 |
|---|
| A More Complicated Example | | A More Complicated Example |
| --------------------------- | | --------------------------- |
| | |
| Although the simple cases like the "foo" example above are not uncommon, | | Although the simple cases like the "foo" example above are not uncommon, |
| many packages are more complicated. We now consider the fictitious "bar" | | many packages are more complicated. We now consider the fictitious "bar" |
| package (example modulefiles in "example/tips-for-code-reuse/bar" directory). | | package (example modulefiles in "example/tips-for-code-reuse/bar" directory). |
| This is admittedly a contrived example, but it displays some of the ways in | | This is admittedly a contrived example, but it displays some of the ways in |
| which we can modify the above simple cases to handle the more complicated | | which we can modify the above simple cases to handle the more complicated |
| needs of some packages. Our "bar" package has the follow characteristics: | | needs of some packages. Our "bar" package has the follow characteristics: |
| | |
|
| * We have two versions of "bar" built, "1.0" and "2.0" | | * We have two versions of "bar" built, "1.0" and "2.0" |
| * For each bar version, we have builds for three different threading models: n | | * For each bar version, we have builds for three different threading models: not |
| othreads, pthreads, and openmp. | | hreads, pthreads, and openmp. |
| * We expect users to use commands specifying both the bar version and the thre | | * We expect users to use commands specifying both the bar version and the thread |
| ading model, e.g. "module load fooB/1.0/pthreads" or "module load fooB/2.0/openm | | ing model, e.g. "module load fooB/1.0/pthreads" or "module load fooB/2.0/openmp" |
| p" | | * The path to the installation directories include both the version number of "b |
| * The path to the installation directories include both the version number of | | ar" and the threading model |
| "bar" and the threading model | | * The package requires the environmental variable BAR_LICENSE_FILE to be set app |
| * The package requires the environmental variable BAR_LICENSE_FILE to be set a | | ropriately |
| ppropriately | | * All builds of bar version 1.0 use one license file which is different than tha |
| * All builds of bar version 1.0 use one license file which is different than t | | t used by bar version2.0 |
| hat used by bar version2.0 | | * Bar 2.0 nothreads and openmp builds use the same license file, with a complete |
| * Bar 2.0 nothreads and openmp builds use the same license file, with a comple | | ly different name than that used by bar version 1.0. |
| tely different name than that used by bar version 1.0. | | * The bar 2.0 pthreads build uses its very own license file with a very differen |
| * The bar 2.0 pthreads build uses its very own license file with a very differ | | t filename than those used by bar version 1.0 or the other threading models of v |
| ent filename than those used by bar version 1.0 or the other threading models of | | ersion 2.0. |
| version 2.0. | | * The "nothreads" builds have a prerequisite on "fooB", with bar 1.0 wanting foo |
| * The "nothreads" builds have a prerequisite on "fooB", with bar 1.0 wanting f | | B version 1.1, and bar 2.0 wanting fooB version 3.2 |
| ooB version 1.1, and bar 2.0 wanting fooB version 3.2 | | |
| | |
| Even with the above exceptions, there are still more similarities than | | Even with the above exceptions, there are still more similarities than |
| differences between the various modulefile definitions. Like in the "fooA" | | differences between the various modulefile definitions. Like in the "fooA" |
| case, we will have a "common" script that does almost all the work, and stub | | case, we will have a "common" script that does almost all the work, and stub |
| files for each of the variants, but in this case the stub files are expected | | files for each of the variants, but in this case the stub files are expected |
| to define some more variables. Our "common" file, which can be found in | | to define some more variables. Our "common" file, which can be found in |
| the "example/tips-for-code-reuse/bar" directory, looks like | | the "example/tips-for-code-reuse/bar" directory, looks like |
| name "fooB", and the files for this example will be in the | | name "fooB", and the files for this example will be in the |
| | |
| .. include:: ../../example/tips-for-code-reuse/bar/common | | .. include:: ../../example/tips-for-code-reuse/bar/common |
| | |
| skipping to change at line 235 | | skipping to change at line 235 |
|---|
| you can add some code to the | | you can add some code to the |
| appropriate "stubfiles" to handle the added complexity, like was done | | appropriate "stubfiles" to handle the added complexity, like was done |
| with the "prereq fooB" for the "nothreads" builds in the examples. | | with the "prereq fooB" for the "nothreads" builds in the examples. |
| | |
| Alternatively, one can add some additional logic to the common script | | Alternatively, one can add some additional logic to the common script |
| to accommodate the complexity, like was done with the license file | | to accommodate the complexity, like was done with the license file |
| differences between builds. This is the recommended way to handle | | differences between builds. This is the recommended way to handle |
| complexity which is likely to recur in multiple places. Generally, | | complexity which is likely to recur in multiple places. Generally, |
| this is done by: | | this is done by: |
| | |
|
| * adding a parameter to be passed from the stub file to the common file and se
tting appropriately in the stub files (e.g. licensefile in bar/2.0/pthreads) | | * adding a parameter to be passed from the stub file to the common file and sett
ing appropriately in the stub files (e.g. licensefile in bar/2.0/pthreads) |
| | |
|
| * adding logic to the common file to default it appropriately (e.g. licensefil
e for the other builds) | | * adding logic to the common file to default it appropriately (e.g. licensefile
for the other builds) |
| | |
| The above was only a simple example of what could be done, but it shows how | | The above was only a simple example of what could be done, but it shows how |
| modulefiles can leverage the fact that the modulefiles are evaluated in a | | modulefiles can leverage the fact that the modulefiles are evaluated in a |
| full programming language to increase the amount of code re-use, which should | | full programming language to increase the amount of code re-use, which should |
| reduce errors, improve consistency, and in general make things more manageable | | reduce errors, improve consistency, and in general make things more manageable |
| over the long run. | | over the long run. |
| | |
| The tips given above should work with both 3.x and 4.x versions of the Tcl | | The tips given above should work with both 3.x and 4.x versions of the Tcl |
| based environmental packages. They have been explicitly tested on versions | | based environmental packages. They have been explicitly tested on versions |
| 3.2.10 and 4.3.0. | | 3.2.10 and 4.3.0. |
|
| | |
| | .. vim:set tabstop=2 shiftwidth=2 expandtab autoindent: |
| | | |
| End of changes. 4 change blocks. |
|---|
| 21 lines changed or deleted | | 20 lines changed or added |
|---|
"Fossies" - the Fresh Open Source Software Archive 