This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: problem with AC_CONFIG_HEADERS and automake
Dale E Martin schrieb:
Installing config.h (with its non-prefixed defines) can lead to problems
later on, of course.
Right, this is exactly the problem I was facing and so I'm no longer doing
this.
Putting in guards does sometimes not do the right thing either, as
prepackaged software might be build on different hosts with different
configurations leading to different configure`d defines.
I've only defined things in my custom files that should be OK. My
application is implemented C++, and I've got members whose type can depend
on the results of configure tests. For instance, if I need a 64 bit type,
I need to figure out on the platform I'm how to define that. (Is it long,
long long, or uint64, or something else?) So I don't think I have a choice
but to define a header with this info in there.
Yes, another source of library problems that I came across and the
ax...stdint_h macros have come into widespread usage lately which
is a configure-time macro to find _or_ create a header file that
carries the bitspecific inttypes types, ie uint64_t and friends.
That is in one installed config.h the define is ON will in the other it
is OFF, the guard define will make that unconditionally ON.
I'm NOT installing config.h, that was the point of using AC_CONFIG_HEADERS
with my own input files. I'm ONLY guarding multiple inclusion of the
files, too, so multiply defined symbols would actually get flagged as a
problem.
That's great - and in fact it makes for better readibility if you define
only custom defines that drive options in your development environment.
For this case I would not recommend to change over to prefix-config.h,
just keep it, the prefix-config.h thing is simply better to have an
easy start since most projects have a lot of ifdefs on config.h defines
around which makes their developers ask here for they have problems when
that file gets installed (and shipped). To just change over into a
prefixed-defines world happens to be a bit easier than defining your
own header file _and_ *all* ac_define's to be put into that file.
Better put a prefix in there, so that symbols are easily classified to be
the configuration of your lib and not from anyone's else library header.
The macro AX_PREFIX_CONFIG_H might help you here, and it does not even
require you to write your own header.h.in, plus all defines are guarded
as an extra benefit for you. The only problem might be that your
installed header files (and only these) need to be corrected to be
dependent in its ifdef#d on the prefixed symbols. That's been discussed
multiple times on the automake and autoconf mailinglists.
Interestingly, last time I asked about this (a few weeks back) noone
mentioned AX_PREFIX_CONFIG_H. I'll look into that.
The ac-archive macros are not part of the accepted standard breed of
macros as shipped by autoconf, not everyone uses them, knows them, or
likes them. The discussion about prefix-config-h comes up a bit more
often lately as it seems the number of autoconf'd libraries is simply
increasing. Reusable software components seem to get some advancements.
cheers, guido http://ac-archive.sf.net