Re: PACKAGE_FOO macros

[Stewart Brodie]

In message <address@hidden>
          Jeff Squyres <address@hidden> wrote:

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

Do they not?  I'm sure I read that somewhere - perhaps in the section about
installing header files?  Maybe it was even in the automake documentation
instead.

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

The most usual thing you want to do is to include or not include various
headers depending on whether they are present or not.  One way of doing this
is to write .h.in into which config.status can substitute #include
directives.  The current macro I have for this is shown below - it's not
wonderful, but it gets the job done for me.  This is the sort of macro you
need once you have determined that you need the header file, it is not a
feature test macro.

dnl
dnl cond-include.m4
dnl

dnl
dnl PACE_CONDITIONAL_HEADER([<macro tail name>,[header filename])
dnl
dnl Defines a macro pace_include_$1 depending on the earlier result
dnl of a AC_CHECK_HEADERS call setting $ac_cv_header_$1, so that we
dnl can substitute in includes in publically installed header files without
dnl requiring config.h to be present.  This macro hides the grubbing around
dnl suggested in the Goat book and is, IMHO, far more pleasing to the eye
dnl than the arsing around suggested in the book.
dnl 
dnl Use PACE_CONDITIONAL_HEADER([stdio_h],[stdio.h]) in configure.in and
dnl then put @pace_include_stdlib_h@ in your myheader.h.in file where you
dnl would want to include the header.
dnl
AC_DEFUN([PACE_CONDITIONAL_HEADER],[
  AC_CHECK_HEADERS([$2])
  if test "x$ac_cv_header_$1" = "xyes"; then
    pace_include_$1="#include <$2>"
  else
    pace_include_$1="/* #include <$2> */"
  fi
  AC_SUBST([pace_include_$1])
]
)

I couldn't be bothered to make the variable name be dependent on the header
name - I probably ought to have taken the time to do that, but there wasn't
time at the time.

-- 
Stewart Brodie, Senior Software Engineer
Pace Micro Technology PLC
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom         WWW: http://www.pacemicro.com/