Re: Unneeded PACKAGE_TARNAME in config.h

[Bob Friesenhahn]

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