llvm dev - Mar 2006 - [LLVMdev] Virtual "components" for llvm-config

To ease portability headaches, I'd like to support several virtual  
"components" in llvm-config. Possibilities include:

   all: Include all LLVM libraries.
   backend: Include either a working native backend or cbackend.
   engine: Include a working subclass of ExecutionEngine, either the  
JIT or interpreter.

You could, for example, get a typical set of JIT-related libs using:

   $ llvm-config --libs engine bcreader scalaropts

Of course, the exact names and details are up to you folks. :-) But  
if you're building a project outside the LLVM tree, please let me  
know what I can do to make your life easier.

Cheers,
Eric

The only thing that comes to me off the top of my head is to look at the
various LLVM tools and applications and see if there are common sets of
libraries used by the tools. Ideally we'd want to "llvm-config --libs
{toolname}" for each tool where {toolname} is replaced by the virtual
component corresponding to the tool. That might be overkill, but if
there are multiple tools that share the same set of libraries, it makes
sense to me that those comment library sets be implemented as virtual
components. 

In looking at tools, we should also look at the example programs and the
projects such as Stacker. For example, it would be nice to have a
virtual component that includes the libraries necessary for an LLVM
front end translator (source -> llvm bytecode).  It would also be nice
to have a virtual component that includes the libraries necessary for an
LLVM back end target library (LLVM IR -> machine code).  There are
probably a few other categories, for example utilities that only mess
with passes (e.g. opt, LLVM bc -> LLVM bc).

The other ones you've mentioned seem fine, but I could add:

      * transform: Include libraries needed to read and write bytecode
        as well as implement a transform on the LLVM IR once read
      * analysis: Include libraries needed to read bytecode as well as
        implement an analysis on the LLVM IR once read.
      * compile: Include libraries needed to read/write bytecode, run
        all transforms and analyses.

There's probably several more of these but that's my $0.02 worth.

Reid.

On Wed, 2006-03-22 at 17:53 -0500, Eric Kidd wrote:
> To ease portability headaches, I'd like to support several virtual  
> "components" in llvm-config. Possibilities include:
> 
>    all: Include all LLVM libraries.
>    backend: Include either a working native backend or cbackend.
>    engine: Include a working subclass of ExecutionEngine, either the  
> JIT or interpreter.
> 
> You could, for example, get a typical set of JIT-related libs using:
> 
>    $ llvm-config --libs engine bcreader scalaropts
> 
> Of course, the exact names and details are up to you folks. :-) But  
> if you're building a project outside the LLVM tree, please let me  
> know what I can do to make your life easier.
> 
> Cheers,
> Eric
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060322/e265e5a2/attachment.sig>

On Mar 22, 2006, at 11:22 PM, Reid Spencer wrote:
> In looking at tools, we should also look at the example programs  
> and the
> projects such as Stacker. For example, it would be nice to have a
> virtual component that includes the libraries necessary for an LLVM
> front end translator (source -> llvm bytecode).  It would also be nice
> to have a virtual component that includes the libraries necessary  
> for an
> LLVM back end target library (LLVM IR -> machine code).
What would you include in each set?
> There are
> probably a few other categories, for example utilities that only mess
> with passes (e.g. opt, LLVM bc -> LLVM bc).
In many of these cases, you can just ask for the components you need:

   $ llvm-config --libs bcreader bcwriter scalaropts

I think this is pretty reasonable. Do you think we need to provide  
short aliases for all these combinations, or can we just let the user  
specify them manually?

"Virtual" components are quite useful, though, when (a) the exact set
of libraries needed varies by platform or (b) novice users will  
typically link against a given set. So we need to cover both regular  
compiler backends and the ExecutionEngine (because the right set of  
libraries varies between machines) and possibly a few convenience  
packages.

Cheers,
Eric