[LLVMdev] Headers & Libraries

[Reid Spencer]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031113/099b5345/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/099b5345/attachment.sig>