Hi, Using the new AC_INIT syntax breaks AM_INIT_AUTOMAKE([no-define]) rsp. its triple-argument form AM_INIT_AUTOMAKE(,,no):
Given such kind of configure.ac [..] AC_INIT([foo],[0.1],[[EMAIL PROTECTED]]) AM_INIT_AUTOMAKE([no-define]) [..] AM_CONFIG_HEADER(config.h) [..] Using this, PACKAGE and VERSION will not be inserted into config.h, however PACKAGE_BUGREPORT, PACKAGE_NAME, PACKAGE_STRING, PACKAGE_TARNAME, PACKAGE_VERSION will always be added to config.h. This causes conflicts with other config-headers for packages which * share config-headers either from neighboring config-subdirs or external sources [1]. * import one or more of these defines from other packages' headers. Potential fixes: 1. Abandon the 3rd argument and [no-define]. Using the autoconf-2.5x's new AC_INIT syntax, they have become pretty much non-applicable [1] 2. Let automake diagnose that using the new AC_INIT syntax conflicts with the triple-arg AM_INIT_AUTOMAKE. 3. Let autoconf pass the PACKAGE_*-defines on the command line only instead of AC_DEFINE-ing and therehy put them into config-headers. These values then would not be exported outside a build-/source-tree in general. 4. Let automake purge them from being put into config-header. 5. Don't let autoconf define them. Ralf [1] I know, exporting config-headers is considered bad design and should not be applied, but IIRC, this once was the actual reason for having added the 3rd arg to AM_INIT_AUTOMAKE.
