Re: Unneeded PACKAGE_TARNAME in config.h

[Guido Draheim]

You do probably still need to modify a few things in the case that
some of your instealled  files depend on autoconf results in the
form they were placed in config.h - in the target development
system some other options may be present as detected by a
`sh configure` script run in that target system generating a
config.h file in the other project. That might include the same
#define symbol but possibly with a different value. It is not
a good thing to rely on symbols coming from a config.h in an
installed header file, you must be very careful and basically
expert enough to know what your are going to do.

Instead it would be needed to create your custom myconfig.h
file _and_ some package special AC_DEFINEs that will probably
use some prefix to be distinguishable from the special defines
coming from another library installed in the target system, like
  AC_DEFINE(MYLIB_USE_MMAP,...)
  AC_DEFINE(MYLIB_USE_FORK,...)
and yes, those would be copied into the generic config.h as
well that is in your local project and which is not installed.

With the ax_prefix_config_h macro, you can reuse any old
program sources (that are currently being switched over into
a library) that used to have AC_DEFINE(USE_MMAP,...) around.
The only disadvantage over a manually edited myconfig.h, well,
that's the size of the file since quite a few symbols are
prefixed and generated that are never used in the header
files installed along with the library, ready to be shipped
to the target system. Personally, I can live with that.

Btw, changing older sources is quite easy, just make a list
of the #defines in the config.h (that's all the #undef
symbols in config.h.in), and create an sed script that
modifies the #ifdef's in all your header files accordingly.
Well, right, that touches a lot of places, hmmm. ;-)


Bob Friesenhahn schrieb:
> Thanks for this sage advice.  I was not aware of the multi-config file
> feature.
>
> Performing substitutions on all of the defines actually causes a bunch
> of new problems since the package I maintain is also built in
> environments that don't support the configure script.
>
> Bob
>
> On Wed, 30 Apr 2003, Steven G. Johnson wrote:
>
>
> > I would argue that prefixing *every* autoconf #define symbol is the wrong
> > way to do it.
> >
> > When you need to include configuration-specific #defines in an installed
> > library header file, there are typically only a few #defines that you need
> > to install.  Including the 100's of symbols that might be in your
> > config.h.in into your installed header, installed on every system and
> > #included in all sorts of programs you have no control over, is not what
> > you want.
> >
> > What you want is to use config.h internally, and to substitute *only*
> > those definitions that you need into your installed foobar.h.  This is
> > quite easy to do.
> >
> > In your configure.in, do:
> >
> > AC_CONFIG_HEADER(config.h foobar.h)
> >
> > Then, autoheader will generate the full config.h.in for you, with its
> > gazillion #defines, but will not touch foobar.h.in...this latter file you
> > create *manually*, with whatever few #defines that you need for your
> > installed header.
> >
> > Steven
> >
> > Bob Friesenhahn wrote:
> >
> > > Why is this functionality not standard in Autoconf?
> > >
> > > Bob
> > >
> > > On Fri, 25 Apr 2003, Guido Draheim wrote:
> > >
> > >
> > >
> > > > Bob Friesenhahn schrieb:
> > > >
> > > >
> > > > > The package I maintain has no need for these definitions, and in fact
> > > > > they cause problems for other Autoconf users since my package is a
> > > > > library which includes its config.h as part of the installed header
> > > > > files, and these definitions conflict with similar definitions in the
> > > > > dependent application's config.h.
> > > >
> > > > That can happen with other config.h definitions as well,
> > > > and (rpm,deb,whatever) packages might disagree about
> > > > their findings of environment issues as it depends on
> > > > what had been installed during configure time on a
> > > > development system as opposed to those parts in the
> > > > target system. Use AX_PREFIX_CONFIG_H for that, I've
> > > > developed it for the exact purpose to install config.h
> > > > safely as part of the library headers and many libary
> > > > makers have picked it up in the last years.
>
> ======================================
> Bob Friesenhahn
> address@hidden
> http://www.simplesystems.org/users/bfriesen