Re: Unneeded PACKAGE_TARNAME in config.h

[Guido Draheim]

you *.c files do not need to get renamed their #ifdef's as they
can include the local config.h at build time. Neither for local
header files. It is all about the installed header files which
shall not depend on config.h defines as config.h shall never be
installed. So you say there are only two defines of importance.
That's a good thing, just be sure not to introduce any config.h
dependency into installed header files later on, your original
question did show that developers have the tendency to get
down the easy way with just picking up the config.h defines and
ask for a way to install the config.h file then.

Let me clarify that the notion of "229 visible config.h defines"
is not quite correct as these are prefixed defines that can never
be the same symbol as that from a (generic) config.h define or those
defines from another library with a prefixed config.h - in here
it does not matter that only two are needed as the others do not
give you any trouble, especially not the way indicated originally
with two libraries having the same symbol, possibly with a
different value.

In either case, you are not required to rename all sources, it's
only about the two defines used in the header file, may they be
set in a manual myconfig.h or a myconfig.h automatically derived
from config.h - in either case the myconfig.h should never contain
a #define that has no such library-specific prefix that will ensure
that the symbol could be of the same name as another library may
export it. Do not put some HAVE_* or USE_* clause into some
myconfig.h getting installed, it's an error, always call it
MYLIB_HAVE_* or MYLIB_USE_*, that's all I wanted to make absolutly
known.

best wishes for your release, guido          http://ac-archive.sf.net

Bob Friesenhahn schrieb:
> It looks like this fantastic recommendation is going to allow me to
> reduce the number of visible config.h defines down from 229 to only 2
> with very little effort on my part.
>
> If the 229 definitions were re-named, then I would have quite a bit of
> work to do in order to adapt the sources for the re-naming.  Since the
> package is very close to release, that approach would be untenable.
>
> Thank you very much!
>
> 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