Could you be more specific as to the "environment-modules" packages?
Do these produce a stand-alone executable, or do these require to be
installed on both the development and target environments (machines)?
Part of the issue is having the environment for a build requiring
versions or entire packages that are not available in the "stock"
distribution, but part is having the environment available at run-time
for the built program.
Does this also work for buildable environments that require libraries
incompatible with the "stock" distribution, particularly after the build
during run-time?
Yasha Karant
On 10/16/2013 01:28 PM, Jeffrey Anderson wrote:
> It seems to me that the "environment-modules" package available from
> EPEL can address many of your needs.
>
> We use it to provide access to multiple versions of python, gcc, boost,
> gsl and many other tools and libraries, all without interfering with
> necessary system-level operations. It is quite flexible, has a
> relatively low learning curve, and is widely used. It allows users to
> easily switch back and forth between different versions of these tools.
>
> Need python 2.7.2?
> 'module load python/2.7.2'
>
> Want to switch to 2.6.4?
> 'module switch python/2.6.4'
>
> Want to go back to the default system python?
> 'module unload python'
>
> and so on.
>
> Jeff
>
>
> On Wed, Oct 16, 2013 at 1:11 PM, Yasha Karant <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> On 10/16/2013 09:12 AM, Jim Fait wrote:
>
> I run into this all the time, as we have a large number of
> somewhat incompatible software packages that we are required to
> have. What we have ended up doing is placing the real
> executable somewhere outside the normal path, and then putting a
> script with same name in /usr/local/bin or /opt/local/bin that
> encapsulates all of the foreign dependencies and environment.
> That way, the particular package can live with its
> requirements alongside the production system, with very few
> problems seen by the end user.
>
> Of course, this means writing a number of scripts, in our case a
> couple hundred, that stay fairly static with changes in the OS
> or the package in question, and that hide all of the nastiness
> that otherwise would happen, like a PATH environment variable 10
> line long.
>
> Hope this idea helps.
>
> Jim
>
>
> Your example is one of the accepted methods for enabling the idea of
> polymorphism and encapsulation within an otherwise procedural
> imperative, possibly structured, environment. Assuming that what
> you are describing is for both the build environment and the
> execution environment of the environment/application being built, it
> should (in most cases) work. And -- it should be the norm when
> providing application building environments that do NOT require a
> virtual machine (e.g., maintaining a "more modern" Linux under
> VirtualBox under SL6x).
>
> I do not know which applications/environments you support in this
> way. A list of all that are not subject to for-fee or equivalent
> non-distributable licenses and for which you are willing to provide
> the scripts greatly would be appreciated. Maintaining such
> environments across new major OS environment releases often entails
> a large amount of effort.
>
> Yasha
>
>
>
>
> --
> --------------------------------------------------------------
> Jeffrey Anderson | [log in to unmask]
> <mailto:[log in to unmask]>
> Lawrence Berkeley National Laboratory |
> Office: 50A-5104E | Mailstop 50A-5101
> Phone: 510 486-4208 | Fax: 510 486-4204
|