[LLVMdev] PATH and LD_LIBRARY_PATH

[dpenry]

>      2. Install - That is, set your PATH and LD_LIBRARY_PATH to one
>         place and "make install" the build results into that directory.
>   

I'm just starting to use LLVM, but this really feels like the easiest 
way to go.  I've been a developer of the Liberty Simulation Environment 
for several years now, and the question of how to manage environments 
was an important one for us, which I think we got partially wrong.

We wanted to be able to have both inter-module shared bin/lib/share 
directories as well as the ability to direct each module to its own 
individual bin/lib/share and the ability to use the source directories 
for that as well (compiling in place).  We went with a solution where 
each module had its own set of environment variables pointing to its 
bin/lib/share with a script which allowed the user to set all these 
values and then created the proper PATH and LD_LIBRARY_PATH and 
CLASSPATH and PYTHONPATH.  How has this worked out?  We're up to around 
30 environment variables, but AFAIK none of us actually sets them to 
different values than the defaults -- no one tries to point them to the 
source directories -- though this is still supported and is somewhat 
hard to maintain.  We've found it to be much easier to use the shared 
directories so we only have to think about a single environment 
variable.  BTW, having so many variables creates a huge environment 
which has occasionally interfered with software which has to transfer 
it, such as Condor.

So, I'd suggest the use of a single LLVM_ROOT for the parent of a shared 
bin/lib/share and which you'd just use for the prefix when calling 
configure.  This is also very compatible with installing LLVM as the 
system compiler.

An install-based system also makes it relatively painless to deal with 
branches, releases, multiple versions, and multiple architecture/OS 
combinations; you simply set different builddirs and install paths for 
each.  The way I've organized this for myself in Liberty is with the 
following directory structure:

Liberty
    Trunk
            src
                various modules
            build
                arch/OS1
                arch/OS2
            Install
                   arch/OS1
                         bin
                         lib
                         share
                   arch/OS2
                         bin
                         lib
                         share
    Branch1
          <same structure>
    Tagged release-I-have-to-support
          <same structure>

            
You can consider the level under Liberty to be the different 
environments.  I then have a startLiberty "environment" script which 
takes an environment name (defaulting to Trunk) as its command-line 
argument, figures out the Install path taking into account the arch/OS 
on which it is running, and calls the Liberty environment variable 
setting script with appropriate options.  Note that to make the 
switching of arch/OS work, the builddir and sourcedir must not be the 
same and when I switch the arch/OS I'm working on within an environment 
I have to clean out various autoconf caches and rerun configure.  I've 
got another script which does that for me.   But I don't know that LLVM 
really needs to provide scripts to manage at this level of granularity; 
certainly having the arch/OS support is overkill for someone who works 
on only one system and other Liberty developers have used different 
organizations.

--David