On Fri, 2003-11-14 at 10:56, Alkis Evlogimenos wrote:> On Friday 14 November 2003 12:45 pm, Brian R. Gaeke wrote: > > > So what they call "system" headers are basically installed > > > headers and user headers are internal ones. In the context of llvm every > > > header that is under inlcude is a "system" header (because when we write > > > an install target it will end up in /usr/include/llvm) otherwise it is a > > > user header. > > > > We don't want a user to compile a new copy of LLVM using the headers of > > a previously-installed version of LLVM. > > including with "" will not accomplish that though any less than including with > <>. In both cases you will need to specify the correct -I flags to the > compiler.Let's be clear about something here. There are two cases for #including LLVM header files. The first case is when compiling LLVM itself. The second case is when you're using a compiled/installed version of LLVM. Life gets simpler when #including for both cases is identical. This is what I did in my XPS project. All the source code is in a directory structure like this: xps/<module>/Code.h xps/<module>/Code.cpp There is no separation of headers and cpp files. When I specify my makefiles, I indicate which headers are public (installable) and which are private (not installed). When I compile XPS, I ALWAYS use: #include <xps/<module>/Code.h> The same form of #include is used when compiling something else that uses XPS because the headers get installed in: <installdir>/include/xps/<module>/Code.h. For compiling XPS, all I need is -I$SRCDIR -I$OBJDIR For using XPS, all I need is -I$INSTALLDIR/include Note that if you are installing to INSTALLDIR=/usr or /usr/local, then the single -I$INSTALLDIR/include works for EVERY installed package you might want to use. This arrangement has worked well and I'd advise LLVM to follow a similar pattern to avoid end-user confusion (like mine) down the road. -------------- 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/0567f807/attachment.sig>
On Friday 14 November 2003 01:22 pm, Reid Spencer wrote:> There is no separation of headers and cpp files. When I specify my > makefiles, I indicate which headers are public (installable) and which > are private (not installed).IMO it is better to include with "" internal header files that are never installed as is the case with all headers under lib. It makes file self-documenting in terms of headers being public or private which in turn helps when browsing the code as you know where to look for an included header.> This arrangement has worked well and I'd advise LLVM to follow a similar > pattern to avoid end-user confusion (like mine) down the road.As Chris said this is not of high priority right now. I think it would be nice to have but I am not sure if everyone is convinced (or even anyone else in the group). If/when we decide to go for it, it may be best if we open a bug for it and let some contributor handle it, as there are much more important/ interesting issues we need to address and the cost/benefit ratio of this issue is very low. In any case, we will get more discussion on this on Sunday, so let's hold our breath until then... -- Alkis
On Fri, 2003-11-14 at 11:49, Alkis Evlogimenos wrote:> On Friday 14 November 2003 01:22 pm, Reid Spencer wrote: > > There is no separation of headers and cpp files. When I specify my > > makefiles, I indicate which headers are public (installable) and which > > are private (not installed). > > IMO it is better to include with "" internal header files that are never > installed as is the case with all headers under lib. It makes file > self-documenting in terms of headers being public or private which in turn > helps when browsing the code as you know where to look for an included > header.I agree whole heartedly. When I said "no separation of headers and cpp", I meant that they XYZ.h and XYZ.cpp live in the same directory, the XYZ.h isn't placed somewhere else in the directory structure.> > > This arrangement has worked well and I'd advise LLVM to follow a similar > > pattern to avoid end-user confusion (like mine) down the road. > > As Chris said this is not of high priority right now. I think it would be nice > to have but I am not sure if everyone is convinced (or even anyone else in > the group). If/when we decide to go for it, it may be best if we open a bug > for it and let some contributor handle it, as there are much more important/ > interesting issues we need to address and the cost/benefit ratio of this > issue is very low. > > In any case, we will get more discussion on this on Sunday, so let's hold our > breath until then...Agreed. I'll volunteer to do the work but I won't bother if the result is likely to be met with hostility :). I'd rather we all agree on a plan, which might include doing nothing. If the plan is acceptable then I don't mind "making it so". 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/20031114/9d8f35d2/attachment.sig>