Re: autoheader deprecated?

[Ralf Wildenhues]

Hello Christophe-Marie,

* Christophe-Marie Duquesne wrote on Tue, Apr 28, 2009 at 06:32:40PM CEST:
> I've read it was deprecated to deliver the file config.h generated by
> autoheader (or whatever name you give it) in a project (see (1)).

Since the term "deliver" is a bit unclear in this context, at least
to me (being fairly entrenched in autotools lingo ;-)
I would reformulate it like this: it is not suitable to install
(as in "make install") a config.h file, nor of course to distribute
(as in "make dist" to produce a tarball) it to your users.

> So, if I understand well, _none of the files of my project should
> #include <myproject/config.h>_.

None of those header files that are installed.  In automake lingo: none
of the headers listed in include_HEADERS and similar.

> However, I need to pass some definitions to the compiler, and I don't
> see how to do it in an elegant way without including config.h.

Many projects can cope without platform-dependent settings in public
header files, and only use them in private headers and in .c source
files (or whatever other language you're using).

> Not using autoheader is a solution: then every preprocessor definition
> is passed to the compiler by -D flags, but the output of the
> compilation is quite unreadable.

It is not really a solution either if any installed headers depend upon
those -D flags: any other project using your public headers will have to
get these defines right; and while it is rather common to be the case on
the same system, it might not always be, with more than one compiler
installed, multi-ABI, and whatnot other kinds of build differences.
Also, your users may not use autotools at all in order to build their
packages, so providing those defines might be quite some burden for
them.

There is another technical reason against this strategy, namely that
some compiler drivers are shell scripts, and the authors of said scripts
were not careful enough to do proper quoting when passing on the flags
they receive, and as a result, some of the fancier-quoted -Ddefines on
the command line may get mangled through these scripts.

> I guess this is not the only solution, since being obliged not to use
> autoheader would more or less make autoheader deprecated, and I did
> not find any information about this.

autoheader is not deprecated.  Making public headers
configuration-agnostic is cool, though.  If you can't, use can for
example use the AX_PREFIX_CONFIG_H macro from the Autoconf Macro
Archive, to move your config.h to a package-prefixed namespace.

Or you have two generated headers, one by autoheader (which has all the
defines, and is used only internally), and another, where the template
file is generated manually by you, and which only lists
  #undef MACRO

for macros which are in your package-private namespace anyway.
I'd recommend this method when the number of defines you need in public
headers is very small.

Note that only the first header listed in AC_CONFIG_HEADERS will have
its template generated by autoheader.

> So, could someone provide me a method for using autoheader and
> AC_DEFINE directives in my configure.ac without including config.h in
> my project files?

See above.

> (1): The fedora packagers refuse to include it in their distribution:
> https://bugzilla.redhat.com/show_bug.cgi?id=489233#c4, at the end of
> the comment. If I understand well, the "bad side effect" would occur
> if you #include<foo_package> and <bar_package> and the two of them
> contain a config.h with conflicting preprocessor directives.

Yes.  Fedora packagers are being good in telling you this.

> PS: I do read as much documentation as I can, and I did browsed the
> mail archive before posting. However, if this has already been
> discussed here or put in the doc, please be kind enough not to pardon
> me.

You're doing fine.

Hope that helps.

Cheers,
Ralf