Re: Unneeded PACKAGE_TARNAME in config.h

[Guido Draheim]

Au contraire, what can be easier than injecting a single macro
into your configure script? No need to manually edit a myconf.h.in
file, and to keep it sane along! Sure, one does not need _all_
the symbols generated, well. - And there's one more thing: people
that use autoconf are used to set #ifdef HAVE_* things all around,
and they can switch over just easily. So you come around and turn
your program into a library (a common way of evolution by the way)
with all those HAVE_* things around and in the headers, now all
you need to do is to place #ifdef PKG_HAVE_* things in there instead.
It couldn't be easier! No brainwork here! How do you beat that? ;-)=)

cheers, guido

Steven G. Johnson schrieb:
> 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.