[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Advice on the project structure for a library

From: Bob Friesenhahn
Subject: Re: Advice on the project structure for a library
Date: Tue, 3 Jun 2008 09:45:37 -0500 (CDT)

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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]