Somehow I keep forgetting to archive pertinent information about this, so I forget the details each time I have to do it with a new machine.
Anyway, here's the link to information courtesy of a group at NASA. The notes seem fairly complete, so I do not see a need to make any modifications as my own set of notes here:
https://modelingguru.nasa.gov/docs/DOC-2015
Updated 1/16/2015:
It would appear additional notes are in order for some relatively new revelations as I tried to get a new Mac Mini started (see http://cwleehpc.blogspot.sg/2015/01/update-documenting-fresh-mac-mini-setup.html)
1. The Tcl library and headers are a prerequisite for Modules. On my older MacBook Pro, this prerequisite was satisfied before I had thought to document any setup process from scratch. The default Tcl/Tk setup on Yosemite does not appear to lend itself easily to satisfying this prerequisite, and so I decided to use Homebrew to do this.
Anyway, here's the link to information courtesy of a group at NASA. The notes seem fairly complete, so I do not see a need to make any modifications as my own set of notes here:
https://modelingguru.nasa.gov/docs/DOC-2015
Updated 1/16/2015:
It would appear additional notes are in order for some relatively new revelations as I tried to get a new Mac Mini started (see http://cwleehpc.blogspot.sg/2015/01/update-documenting-fresh-mac-mini-setup.html)
1. The Tcl library and headers are a prerequisite for Modules. On my older MacBook Pro, this prerequisite was satisfied before I had thought to document any setup process from scratch. The default Tcl/Tk setup on Yosemite does not appear to lend itself easily to satisfying this prerequisite, and so I decided to use Homebrew to do this.
- brew tap homebrew/dupes (Tcl/Tk is not part of the standard repository)
- brew install tcl-tk
“This formula is keg-only, which means it was not symlinked into /usr/local.
Mac OS X already provides this software and installing another version in
parallel can cause all kinds of trouble.
Tk installs some X11 headers and OS X provides an (older) Tcl/Tk.
Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:
LDFLAGS: -L/usr/local/opt/tcl-tk/lib
CPPFLAGS: -I/usr/local/opt/tcl-tk/include”
which is then made use of in the following (preliminary) configure line to Modules:
./configure --prefix=$INSTALL_PATH/modules-3.2.10 --with-tcl-lib=/usr/local/opt/tcl-tk/lib --with-tcl-inc=/usr/local/opt/tcl-tk/include
This line actually fails, which leads us to point 2.
2. The latest version of Modules does not check for a recent function deprecation in Tcl/Tk. This fact was captured in the following post: http://sourceforge.net/p/modules/bugs/62/
This forces a final modification to the configure line that works:
./configure CPPFLAGS="-DUSE_INTERP_ERRORLINE" --prefix=$INSTALL_PATH/modules-3.2.10 --with-tcl-lib=/usr/local/opt/tcl-tk/lib --with-tcl-inc=/usr/local/opt/tcl-tk/include
3. 2 warnings show up during the configure process:
configure: WARNING: will use MODULEPATH=$INSTALL_PATH/modules-3.2.10/Modules/modulefiles : rerun configure using --with-module-path to override default
configure: WARNING: will use VERSIONPATH=$INSTALL_PATH/modules-3.2.10/Modules/versions : rerun configure using --with-version-path to override default
configure: WARNING: will use VERSIONPATH=
My approach was to ignore them. The rationale behind this was so I allowed each future upgrade of Modules to be installed with their default (and consistent) relative paths. Meanwhile, I could control where my own module files can be hosted using the MODULEPATH environment variable at shell startup (in my case, bash).
No comments:
Post a Comment