Hi John,
On Monday 15 December 2008 22:39:41 John Hearns wrote:
> A smart thing to do is to install version 1.0.8 to /usr/local/mpich2-1.0.8
> then create a link from /usr/local/mpich2 to point to this.
> Then, if you put /usr/local/mpich2 {bin/lib} into your path as a user you
> will always be up to date.
I've been doing this for some time, but at some point, it raised some issues.
Modifying the default version of a MPI lib is not necessarily something
average users really like. From my experience (insert the mandatory YMMV
here), most users don't really care about the MPI implementation/version their
program uses, as long as it runs and performs reasonably.
I too used to install libraries in their own dirs and link the default path to
the latest version. But I had my share of "Did you change anything? My job
doesn't run anymore, and it was working perfectly fine last week."
So now, I've adopted the über-conservative approach, which is to still install
new versions of libraries in their own dirs, but let the user decide if she
wants to use them or not: I don't link the default path anymore, so that
people having used MPICH 1.0.6 for months will still continue to use it
(assuming they know they use MPICH 1.0.6...) without having to modify anything
in their scripts. And at the same time, people wanting to use a more recent
version are free to do so. But that has to be a voluntary move.
Once again, this is probably pretty dependent on your audience.
> At this point, the clustering gods are laughing at me.
> An even smarter thing to do is to use modules
Yep, that's definitely easier to manage from the user standpoint. For each new
version, a new module file, the appropriate announcement in the media channel
used to communicate with users, and everybody's happy. :)
Cheers,
--
Kilian