[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 2.0.0.12 (X11/20080226) |
-----BEGIN PGP SIGNED MESSAGE-----
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.
Regards,
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIKd16dcgqmRY/OH8RAsdvAKCIhgPOYfNUN4QkryO0IMW6h6VinQCfdAa5
bR/Iy6D4cYZkTDQc5WkNv7Q=
=U95M
-----END PGP SIGNATURE-----
- #define warnings when using various autotools projects, aaragon, 2008/05/12
- Re: #define warnings when using various autotools projects, John Calcote, 2008/05/13
- Re: #define warnings when using various autotools projects, Bob Friesenhahn, 2008/05/13
- Re: #define warnings when using various autotools projects, Bruce Korb, 2008/05/13
- Re: #define warnings when using various autotools projects, Ed Hartnett, 2008/05/13
- Re: #define warnings when using various autotools projects, Ralf Wildenhues, 2008/05/18
- Re: #define warnings when using various autotools projects, aaragon, 2008/05/18
- Re: #define warnings when using various autotools projects, Stepan Kasal, 2008/05/19
- Re: #define warnings when using various autotools projects, Peter Simons, 2008/05/23
- Re: #define warnings when using various autotools projects, Ralf Wildenhues, 2008/05/24