Re: PACKAGE_FOO macros

[Jeff Squyres]

On Thu, 24 Oct 2002, Raja R Harinath wrote:

> > 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.

Two things:

1. The information to portably build my package is frequently the same as
the information that I need to present to users (or at least a subset of
it).  Why should I need two mechanisms to process the same information?

2. The autoconf 2.54 docs do not mention that generated .h files are
supposed to be private.

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

Why?

There is already a mechanism in place to generate .h files -- why should
users have to go re-create this mechanism just to create their own
public_config.h file?  Consider -- users will have to implement all the
exact same things that AC_DEFINE, AC_OUTPUT, AH_TEMPLATE, AH_TOP, and
AH_BOTTOM do (to name a few off the top of my head).  Isn't autoconf
supposed to releive authors of this burden?

Again -- the automake maintainers have seen the wisdom of not forcing
their own #defines upon program authors (i.e., the "no-define" option).
Can't autoconf do the same?

{+} Jeff Squyres
{+} address@hidden
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/