AM_INIT_AUTOMAKE([no-define]) vs. AC_PACKAGE_*

[Ralf Corsepius]

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],address@hidden)
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.