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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
