[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
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/