Re: Handling PACKAGE, PACKAGE_VERSION, etc. with multiple libraries

On Thu, 2004-08-05 at 22:40, Bob Friesenhahn wrote:
> On Thu, 5 Aug 2004, J.T. Conklin wrote:
> >> ... You are polluting the preprocessor symbols' with #defines. This is
> >> considered bad design.
> >
> > I'm not exactly sure what you consider "bad design", but I think I
> 
> The existence of autoconf at all is clear evidence of "bad design". 
> [..]

:-)

As far as autoheaders are concerned:

* The symbols/defines in autoheader generated headers are not namespace
safe and therefore can clash with symbols/defines from arbitrary other
headers at anytime, anywhere when using them in public headers or
directly exporting autoheaders.

[IMO, autoconf/automake should have a means to implement autoheader
namespaces, but ... we've had this discussion several years ago and the
conclusion then was that all documented autoconf/automake generated
defines have to considered to be reserved for autoconf :-/]

* Such autoheader-defines reflect the situation/configuration a
configure script had detected on one particular system, at one point in
time. Systems' setups change over the time, so the values being
hard-coded into autoheaders may become invalid rsp. may be invalid on
other systems.
[Consider distributing binary packages. Exporting autoheaders is kind of
trying to export a "static registry".]

* Autoheader defines can be influenced by compiler/preprocessor flags
having been used during configuration. I.e. even "system defines" or
"standard defines" you may assume to be constant only reflect your 
configuration's momentary situation. Even "sizes of types" or
"target/cpu has type" features depend on compiler flags.
[Consider multilibs/multiarch'ed systems.  You'd have one config.h per
cpu-variant ("multiheaders").]
...

Ralf