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
On Thu, 2006-03-23 at 00:58 -0500, Eric Kidd wrote:> On Mar 22, 2006, at 11:22 PM, Reid Spencer wrote: > > LLVM back end target library (LLVM IR -> machine code). > > What would you include in each set?I dunno. You want me to actually think about this stuff? :) I'd have to derive the actual set of required libraries, but I'm lacking motivation for that task right now.> > > 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.Yup.> Do you think we need to provide > short aliases for all these combinations, or can we just let the user > specify them manually?I think just using the "long hand" is fine for now. If it becomes cumbersome and repetitive then we can create the "virtual components" (shorthand) as needed.> "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.Yup. Note that I just committed a change to LibDeps.txt to reflect the fact that ExecutionEngine now no longer depends on JIT or Interpreter objects. This change was made by Chris today. Reid -------------- 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/a050c147/attachment.sig>
On Mar 23, 2006, at 1:22 AM, Reid Spencer wrote:> I dunno. You want me to actually think about this stuff? :) > > I'd have to derive the actual set of required libraries, but I'm > lacking > motivation for that task right now.OK, here's my current minimalist proposal: backend: Either a native backend or a C backend. engine: Enough libs to run ExecutionEngine using either a JIT or interpreter. all: All LLVM libraries. Please feel free to suggest better names. :-) Cheers, Eric