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.