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>
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>
Just a comment on llvm headers. We currently use: #include "llvm/Codegen/LiveVariables.h" which causes an extra unnecessary lookup to compared to: #include <llvm/Codegen/LiveVariables.h> because it looks for the header file in the directory of the source file it includes it first before looking at the rest of the include path. Of course the header will never be there since the full path is specified. #include "" should only be used when headers are specified using relative paths. In our case the majority of header inclusions (if not all) use relative paths so we may want to consider either converting all our #include "" to #include <> or change header file inclusions to use relative paths. I don't see any advantages of one over the other but what we have today is not strictly correct :-) -- Alkis
On Fri, 14 Nov 2003, Alkis Evlogimenos wrote:> #include "" should only be used when headers are specified using relative > paths. In our case the majority of header inclusions (if not all) use > relative paths so we may want to consider either converting all our #include > "" to #include <> or change header file inclusions to use relative paths. I > don't see any advantages of one over the other but what we have today is not > strictly correct :-)#include <> is for system headers: http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html#Include%20Syntax While LLVM is slowly moving that direction, we are not yet considered to be required by the "system". -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Fri, 2003-11-14 at 10:03, Alkis Evlogimenos wrote:> Just a comment on llvm headers. We currently use: > > #include "llvm/Codegen/LiveVariables.h" > > which causes an extra unnecessary lookup to compared to: > > #include <llvm/Codegen/LiveVariables.h> > > because it looks for the header file in the directory of the source file it > includes it first before looking at the rest of the include path. Of course > the header will never be there since the full path is specified. > > #include "" should only be used when headers are specified using relative > paths. In our case the majority of header inclusions (if not all) use > relative paths so we may want to consider either converting all our #include > "" to #include <> or change header file inclusions to use relative paths. I > don't see any advantages of one over the other but what we have today is not > strictly correct :-)I couldn't agree more :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031114/6132070e/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/20031114/6132070e/attachment.sig>