[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unneeded PACKAGE_TARNAME in config.h

From: Guido Draheim
Subject: Re: Unneeded PACKAGE_TARNAME in config.h
Date: Thu, 01 May 2003 01:32:11 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826

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
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, 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

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.


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 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, do:

AC_CONFIG_HEADER(config.h foobar.h)

Then, autoheader will generate the full for you, with its
gazillion #defines, but will not touch latter file you
create *manually*, with whatever few #defines that you need for your
installed header.


Bob Friesenhahn wrote:

Why is this functionality not standard in Autoconf?


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]