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

[J.T. Conklin]

Ralf Corsepius <address@hidden> writes:
>> Both ACE and TAO create config.h files which are used in compiling the
>> respective libraries.  The config.h files are also installed and are
>> referenced by library headers, as the macros defined within are needed
>> in the implementation of inline functions, etc.
>> 
>> The ACE and TAO macros do not conflict, since they use ACE_ and TAO_
>> prefixes.  The system macros like SIZEOF_DOUBLE and HAVE_UNISTD_H do
>> not conflict, since they are defined with the same values. 
> ... 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
disagree.  I've got some ~450 feature test macros, all prefixed with
ACE_ that need to be included in library header, inline, and template
files as they are used in conditionals within.  While it is true that
they intrude in the user's namespace, ACE reserving ACE_* is not much
different that the standard C library's <string.h> reserving str*.

>> But the PACKAGE macros defined by autoconf (PACKAGE, PACKAGE_NAME,
>> PACKAGE_- VERSION, etc.) do.
>> 
>> Fortunately these macros aren't used by either ACE or TAO, so all
>> there is are annoying compiler warnings.  Is there any better way 
>> to handle this so that the PACKAGE macros aren't defined in config.h?

> The standard answer to this problem is (Please search this list's
> archive. Your question is sort of a FAQ popping up every couple of
> months since autoconf-2.5x):

I tried to search the list archive, but it's so spam infested to be
worthless.  If this is as common as it you say it is, it would sure
be nice if it was noted in the autoconf info pages.

> Don't install autoheaders, treat them as private files of a
> package. If you really need to export preprocessor symbols you'll
> have to find other ways to do so (There are many ways to achieve
> this.)

Yes, I can emit a config.h with only my ACE_ #defines myself.  I may
end up having to do that.  I'm not looking forward to it, since auto-
header almost does it right automagically.  It essentially forces me
to come up with a similar tool, as it would be foolhardy to even try
to maintain ~500 feature tests by hand.

   --jtc

-- 
J.T. Conklin