[LLVMdev] Headers & Libraries

[Reid Spencer]

Oops, I was a little hasty. The #include problem results from the need
to specify both -I$OBJDIR/include and -I$SRCDIR/include on the compiler
command line.  This isn't particularly friendly for users of LLVM
working in separated directories. Although I have a workaround for this
particular problem, the larger issues of installing headers/libraries
and what goes in what library remain.

Reid

On Thu, 2003-11-13 at 13:15, Reid Spencer wrote:

> LLVMers,
> 
> I'm running into a fair bit of confusion as I start to *use* LLVM to
> build my own compiler. The issues relate to what is in a given .a or
> .o file, why linking takes so long, and getting LLVM header files to
> include correctly, and the lack of viable "install" target. I'll deal
> with each of these in turn:
> 
> For my own project, I've added an AC_CHECK_LIB line to check for
> libipo.a as a test that the LLVM libraries are available. In order
> to get this to work, I needed to use the last argument of AC_CHECK_LIB
> to specify the dependent libraries. To get this to work correctly, I
> had to specify vmcore.o and -lsupport to linker. Now, the question is,
> why isn't vmcore.o a LIBRARY?  I also note that in the objects
> generated by an LLVM compilation, there are numerous .o files in t
> $OBJDIR/lib/Debug directory. Is that by design? It certain isn't very
> friendly for *users* of LLVM.
> 
> After I got my configure script to detect LLVM libraries correctly, I
> noted that the AC_CHECK_LIB test for libipo.a took longer than the
> entire rest of my configuration script (and I have a big one). It sat
> on the "checking..." line for about a minute. This is happening while
> configure is linking a one line program against three LLVm libraries
> (-lipo vmcore.o -lsupport).  What gives? This shouldn't take so long!
> Am I linking this incorrectly?
> 
> Finally, I started to compile against LLVM source. I adjusted my build
> system to include -I$SRCDIR/include on the g++ command line. But, when
> I compile, I get:
> 
> 
> > In file included from /proj/work/llvm/include/Support/ilist:41,
> > /proj/work/llvm/include/Support/iterator:29:27: Config/config.h: No such file or directory
> > /proj/work/llvm/include/Support/iterator:47:2: #error "Need to have standard iterator to define bidirectional iterator!"
> > /proj/work/llvm/include/Support/iterator:68:2: #error "Need to have standard iterator to define forward iterator!"
> 
> And, from there the compile goes to hell. Note that "Support/iterator"
> and "Support/ilist" are included just fine from the -I$SRCDIR/include
> command line argument but the "Config/config.h" isn't found even
> though the Config and Support directories are in the same location! 
> When Support/ilist includes Support/iterator, it uses "#include
> <Support/ilist>" believe the problem is that iterator:29 has:
> 
> #include "Support/support.h"
> 
> instead of:
> 
> #include <Support/support.h>
> 
> Furthermore, this raises another huge issue which is segregation of
> the LLVM header files. The practice for many open source projects
> today is to place all the header files in a directory that identifies
> the project. For example, when you include a Xerces header file, you
> do so with #include <xercesc/XYZ/File.h>. Similarly for ICU, we use
> #include <unicode/ucstring.h>. The same is true of many other
> packages, mine included. Unfortunately, it is not true of LLVM.  Every
> #include in LLVm should look like: #include <llvm/Module/Header.h>  As
> in #include <llvm/Support/support.h>.  This clearly identifies it for
> end users and ensures that support.h won't get confused with some
> other "Support/support.h", which would be disastrous.
> 
> On a related question, the current "install" target in the Makefile
> system is a no-op. It would be very useful if we had an install target
> that finalized libraries and then copied them and the headers to an
> installation location.  In such a scenario, the user of LLVM only
> needs to worry about one directory for LLVM: the install directory. 
> Right now, I need to know about the $SRCDIR to get headers and the
> $OBJDIR to get libraries.  As I've said before, the install
> functionality comes for free with automake.
> 
> So, my question is, are these things by design? If so, what is the
> rationale and how would I avoid the compilation problem?
> 
> If these things aren't by design, I'd like to open a bug against them
> to get it fixed. Before I can do that, however, we need to have a plan
> for the way things SHOULD build. I'm willing to go along with whatever
> scheme is comfortable for you as long as it ends up being possible for
> LLVM users to utilize LLVM correctly and easily.
> 
> I know you guys are all busy this week. Feel free to delay your
> answer. Funding's more important than answering my questions :)
> 
> Reid.



_______________________
Reid Spencer
President & CTO
eXtensible Systems, Inc.
rspencer at x10sys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031113/772130b6/attachment.html>
-------------- 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/20031113/772130b6/attachment.sig>