Re: PACKAGE_FOO macros

[Raja R Harinath]

Hi,

Jeff Squyres <address@hidden> writes:
[snip]
> 1. generated .h files should always be private
> 2. use ac-archive/AC_CREATE_PREFIX_CONFIG_H
>
> 1. is not always true -- 

It is true for config.h.  Other generated .h files may be for public
consumption, but not so for config.h or whatever is named in
AC_CONFIG_HEADER.

> consider the case of using autoconf to create libraries.  My group,
> for example, has packages that create libraries containing top-level
> .h files that are #included by users.  These .h files frequently
> have to have some kind of results from configure -- such as type
> settings in function prototypes.  This is *not* private data, and
> *needs* to be shared with the user.

Yes.  But, config.h is not meant for this.  It is meant only to
provide enough information to portably build your package.

If you need to install a generated header file to _use_ your package,
you need to do the legwork to generate it properly.

And then, you need to do additional legwork to install it in the right
place, considering some of the possible ways people use $prefix and
$exec_prefix.

Specifically, a generated header file containing system specific
information is not appropriate for installation in $includedir ==
$prefix/include.  It should be somewhere in $exec_prefix.  (Or, you
should place a very very strong warning to people building and using
your package that you don't honour the difference between $prefix and
$exec_prefix.)

[snip]
> More specifically -- having *every* autoconf-generated config.h file
> generate macros by the same name violates the spirit of "separate
> namespaces" in macros.  Since there's only a global namespace for
> preprocessor macros, the only way to segregate them is by different
> prefixes.  But autoconf isn't even giving the user the option to do that
> -- these macros will be named PACKAGE_FOO, regardless of what the user
> wants.

There is no need for config.h to worry about "separate namespaces".
It is a private header.  It is a good thing that config.h is not
easily installable, IMHO.

> Please please please give us a way to turn off 

You can remove AC_CONFIG_HEADER from your configure.ac.

> (or put a prefix in front of) these macros.

It's already in the ac-archive, as you mention above.

- Hari
-- 
Raja R Harinath ------------------------------ address@hidden