<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>
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.<BR>
<BR>
Reid<BR>
<BR>
On Thu, 2003-11-13 at 13:15, Reid Spencer wrote:
<BLOCKQUOTE TYPE=CITE>
<FONT COLOR="#301fe4"><I>LLVMers,<BR>
<BR>
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:<BR>
<BR>
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<BR>
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.<BR>
<BR>
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?<BR>
<BR>
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:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>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!"</PRE>
</BLOCKQUOTE>
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:<BR>
<BR>
#include "Support/support.h"<BR>
<BR>
instead of:<BR>
<BR>
#include <Support/support.h><BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
So, my question is, are these things by design? If so, what is the rationale and how would I avoid the compilation problem?<BR>
<BR>
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.<BR>
<BR>
I know you guys are all busy this week. Feel free to delay your answer. Funding's more important than answering my questions :)<BR>
<BR>
Reid.</I></FONT>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
<BR>
<ADDRESS><FONT SIZE="4"><I>_______________________<BR>
Reid Spencer<BR>
President & CTO<BR>
eXtensible Systems, Inc.<BR>
rspencer@x10sys.com</I></FONT></ADDRESS>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>