[Top][All Lists]

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

Re: #define warnings when using various autotools projects

From: John Calcote
Subject: Re: #define warnings when using various autotools projects
Date: Tue, 13 May 2008 12:27:06 -0600
User-agent: Thunderbird (X11/20080226)

Hash: SHA1

Bob Friesenhahn wrote:
> On Tue, 13 May 2008, John Calcote wrote:
>> But this is very common mistake. It comes from carelessness about which
>> header files are considered part of the public interface, and which ones
>> should be kept private. The generated config.h header file is intended
>> to help BUILD the library on a particular platform, not provide support
>> for consumers of the library through the public interface of that
>> library. And yet I see this happen all the time.
> It is sometimes necessary to provide build-specific typedefs and defines
> in order for the installed header files to correctly represent the
> library interface.  If "config.h" is not used, then a more elaborate
> means needs to be used to make this possible.
> For my own project, I use two "config.h" files.  One is used to build
> the software and the other is trimmed down to support only what is
> actually needed to define the interface header ABI.

And what if a user decided to run "make install" to put your public
headers into his or her /usr/local/include directory? Or even
worse--what if a distro packager decides to provide a "devel" package
for your project that installs your public headers into "/usr/include"?
How is it that you're okay claiming ownership of the one "config.h"
header that is allowed to exist in this directory?

My point is simple: config.h should NEVER be included in a library's
public interface. NEVER. It always causes such problems, and if you find
you need to do it for one reason or another, then you should re-examine
your design for the flaws that you will inevitably find there, if you
look hard enough.

A portable public interface does not need to contain platform-specific
details of any sort. There are always ways to avoid this.

Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE -


reply via email to

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