Re: Advice on the project structure for a library

[Bob Friesenhahn]

On Tue, 3 Jun 2008, Warren Young wrote:
> > Suppose that in one of my public headers, I include one of the other header 
> > files, with <libfoo/headerx.h> style. 
>
> If your headers use the libfoo/header.h style, your users must, too. That's 
> not consistent with your wish above.
>
> To allow your users choice in the matter, your public headers should use this 
> style when pulling in other headers from the same project:
>
>         #include "my-other-header.h"
>
> The use of "" instead of <> tells the compiler to look in the current 
> directory before going through the list of other possible directories. This 
> is exactly what you want when you don't know where the user has installed the 
> headers.  A side benefit is that it protects you if there is a 
> my-other-header.h on the system in one of the other directories in the 
> include path; the compiler will always use the right one.

I think that "suggests" is a better operative word than "tells".  Last 
I checked, the C standard left quite a lot up to the implementation.

When using a VPATH build, the value of double quote syntax may be 
significantly diminished to the extent it does not help at all.  Any 
project using Automake should reliably support a VPATH build as long 
as make supports it (passing 'make distcheck').  Sometimes it is 
necessary to manually inspect generated header dependency files to 
make absolutely sure that the correct headers are used.

With today's messy include directories, creating a directory for the 
project header is a good idea, and so there is no harm to using 
<libfoo/headerx.h> style.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/