[LLVMdev] PATH and LD_LIBRARY_PATH

[Chris Lattner]

On Thu, 19 Jul 2007, Reid Spencer wrote:
>>>      * support - lib/Support, lib/System, autoconf, make support,
>>>        utilities
>>
>> which utilities?  The C++ programs in llvm/utils should not be moved.
>
> No, I was thinking more like "mkpatch" and "llvmgrep".

Makes sense.

>>>      * core - VMCore, Asm, Bitcode and the essential IR tools (llvm-as,
>>>        etc.)
>>
>> I'm still not convinced that this is useful to split out from the rest of
>> the LLVM tree, we should discuss this again after support is split out.
>
> Surely. About the only reason is for modules that only work with the IR
> and don't want to have to compile all of the transforms and targets just
> to use the IR. I know there's no technical difference, its merely a
> developer convenience. In any event, we can discuss later. My point was
> there will be more modules.

yep. we're on the same page.

>> Regardless of the users PATH setting, the build process for  the various
>> modules should invoke the tools from other modules *without* PATH
>> needing to be set.
>
> Yeah, its more LD_LIBRARY_PATH that I'm concerned about. It can and does
> screw up linking if its set wrong.

It screws up *dynamic linking*, not linking.

>> This is only an issue if you have a name collision, right?  IF so the
>> answer is "don't do that" :)
>
> Sure .. this entire email is about striking a balance between making the
> build system "fool proof" and "flexible".

Just make it an error if llvm-config detects a conflict and you're done.

>>>      * Building things can be affected because if you put the wrong
>>>        directory in your LD_LIBRARY_PATH you can end up linking against
>>>        libraries built by the compiler instead of your platform's
>>>        native compiler, which will ultimately fail (very late too).
>>
>> This is only for llvm-gcc?
>
> Yes.

Okay, this is an issue, but it seems like we already have this issue.  In 
any case, it can be fixed through magic (rpath?) that embeds information 
in the generated executable.  I don't know much about this, but I am 
confident we can solve it if/when it is an issue :)

>>>      * Having two llvm-gcc versions (4.0 and 4.2) in separate modules
>>>        could lead to conflicts.
>>
>> The only thing that depends on llvm-gcc is the llvm-test suite.  It's
>> configure script should probably try to autodetect which C front-end you
>> have (4.0,4.2, clang) and "build in" the paths it needs into its
>> Makefile.config.
>
> What if you "have" all three? Which does it pick? It probably needs to
> be a configure or make option. In any event, if you switch compilers and
> don't "make clean" you can end up with link errors (e.g. clang compiled
> object linked with llvm-gcc-4.2)

Okay, let me clarify: the configure script *defaults* to finding one of 
the things you have.  The configure script should also provide an option 
that lets you choose a specific one.  It would be wonderful if you could 
check out llvm-test three times and configure each one to use a different 
cfe.

>> equivalent of "make".  If clang used tblgen for its build, it would know
>> to invoke it from the llvm module, and would use an absolute path
>> generated by the makefile.
>
> That's one way to do it :)

Yep, I think it's pretty important to do it this way.

>>>      * We want to treat each module, as much as possible, as a separate
>>>        entity (very loose coupling), but they are API locked anyway and
>>>        we can't do much about that. The dependencies are real.
>>
>> Yep.  The dependencies are hard dependencies, though it would also be nice
>> to support "optional dependencies" down the line (if you check out "this"
>> in your tree, it enables "that" feature in some other dependent module).
>
> Okay, you can implement that feature :)

Hehe, "down the line" :)

>> The makefiles that build the projects should not depend on PATH.  The only
>> need for PATH to be set is if the user wants to invoke something (like
>> llvm-as, opt, etc).
>
> Yeah, I mixed up two things here. So the user's path might want to have
> all the llvm-top/*/utils directories in their PATH? And if you want to
> keep TestRunner.sh in test, then you need that in your path, and ...
> this just gets awkward quickly.

You only need to add the utilities that you invoke directly and want in 
your path.  The standard build stuff (e.g. make test) can find the 
utilities they need.

> As for build utilities, I'm trying to strike a balance here between hard
> coding paths (which make it brittle) and having it "just work". I think
> its probably fine to put things in "support" that many other modules
> will use. For example, the makefile system itself. That one module name
> can be hard coded.  But, as we go along, there may be other things used
> (e.g. the hlvm utilities for all of hlvm's front ends) during build. To
> avoid PATH for such things we need to know the module its in, *OR* just
> always reference the installed thing and then you have perfect control
> over which utility is being used, even while developing experimental
> versions of that utility (into module/Debug/bin).

I suggest that projects publish makefile fragments.  For example, 
makefile.core could provide a fragment that includes:

LLVMToolDir := $(LLVMTopObjDir)/core/$(BuildMode)/bin
LLVMLibDir := $(LLVMTopObjDir)/core/$(BuildMode)/lib
LLVMAS   := $(LLVMToolDir)/llvm-as$(EXEEXT)
LLC      := $(LLVMToolDir)/llc$(EXEEXT)
LLI      := $(LLVMToolDir)/lli$(EXEEXT)
...

If the hlvm project wnated to use this, it would just include 
$(LLVMTopDir)/core/Makefile.core

to get all these definitions.  That way, you now have absolute paths 
available everywhere.

>>>      * Does every module need its own "llvm-config" program?
>>
>> It would be nice if this was shared, perhaps to live in the support
>> module?
>
> I was thinking the same thing, but then it can't give you all the
> project specific configuration, just the stuff that support knows about
> (which is a lot, but not everything).  Recall that llvm-config needs to
> be built after all the libraries have been built so it can pick up all
> the dependencies and generate the -l options in the right order. So,
> conversely, it actually needs to be in a module that is the LAST one
> built, not the first.

Great point.  It sounds like llvm-config should be split into two parts: a 
common part shared by all the actual tools, and a project-specific part 
that "configures" llvm-config.

> I'm too forgetful for that. I want to run something that would put me in
> "my backport patch branch environment" so I can just type "llvm-as" and
> it gets the right one. Then all I have to do is remember to run that
> thing.

Sure, I agree that's useful, I just think it is something people can 
develop on their own.  Alternatively, we can provide scripts in utils for 
people to use if they want.

>>>     2. Install - That is, set your PATH and LD_LIBRARY_PATH to one
>>>        place and "make install" the build results into that directory.
>>
>> We *need* to support make install, but we also should not make it
>> required.  End users just want to 'check out/download + build + install',
>> they don't want to mess with their environment or anything else for that
>> matter.
>
> So, you're saying if you just want to use LLVM than invoke "install" and
> set your path to the install location.

Yes.

>>>     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.
>>
>> Ick.
>
> Okay, disapproval noted. Got anything substantive to add to that?

I think a combination of:
1) letting people add stuff to their PATH as they want to, and
2) providing simple scripts in utils for people who want to use them

is sufficient.

>> Worse case they can use absolute paths if they want.
>
> So, basically .. #1 :)

Yep.  We can always improve it later.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/