[LLVMdev] PATH and LD_LIBRARY_PATH

[Chandler Carruth]

One further issue I would like to raise:

    * At some point, some people (crazies like me?) are going to want
to install LLVM as the
      default and primary system compiler. Some of us may even want to
integrate this
      process into a distribution's package management. Anything that
makes this saner
      is appreciated, and it might not conflict with the already
mentioned serious concerns.

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

I personally really like this, with some more or less involved
addition of the next one...

>      3. Shell - Provide some shell functions and aliases to manage
>         setting the environment   correctly. This could even use the
>         ModuleInfo.txt file to glean dependencies. For example,the
>         llvm-top module could have a "setenv.sh" scrip that is invoked
>         with ". ./setenv.sh"to set the environment for whatever is
>         checked out in that llvm-top. We'd need one for each type of
>         shell and users would have to remember to run it.
>      4. Other - got any other ideas?
>

What about providing make install, with scripts to assist in setting
up appropriate ./configure prefixes, make installs, and environment
variables to utilize "staged" installs for each environment. This
would allow the behavior in these development "environments" mimic
very closely the potential installed "real world" behavior of the
packages. The root _is_ an environment, its just that we provide
scripts (or users provide scripts) which construct staged installs to
set up "environments" for on-going development. These scripts could
start very minimal, or not at all, and be built up over time without
hamstringing anyone's homegrown scripts (such as mine) which are based
entirely on the existing make install functionality.

For detecting installed libraries, I actually like module-specific
*-config scripts, or leveraging pkg-config (as ugly as it is) to do
module-specific stuff without code duplication. This allows flexible
and easy ./configure dependency resolution on installed packages, be
they installed in '/', or some staging location.

My 2 cents. =]
-Chandler

PS: I would be willing to contribute to seeing this smoothly work,
especially with the config scripts, and autoconf magic to enforce
dependencies.