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

[Akim Demaille]

| >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
|  Ralf> Hi,
|  Ralf> Using the new AC_INIT syntax breaks AM_INIT_AUTOMAKE([no-define]) 
|  Ralf> rsp. its triple-argument form AM_INIT_AUTOMAKE(,,no):
| 
|  Ralf> Given such kind of configure.ac
|  Ralf> [..]
|  Ralf> AC_INIT([foo],[0.1],address@hidden)
|  Ralf> AM_INIT_AUTOMAKE([no-define])
|  Ralf> [..]
|  Ralf> AM_CONFIG_HEADER(config.h)
|  Ralf> [..]
| 
|  Ralf> Using this, PACKAGE and VERSION will not be inserted into config.h,
|  Ralf> however
| 
|  Ralf> PACKAGE_BUGREPORT, 
|  Ralf> PACKAGE_NAME, 
|  Ralf> PACKAGE_STRING, 
|  Ralf> PACKAGE_TARNAME, 
|  Ralf> PACKAGE_VERSION
| 
|  Ralf> will always be added to config.h.
| 
|  Ralf> This causes conflicts with other config-headers for packages which 
|  Ralf> * share config-headers either from neighboring config-subdirs or
|  Ralf> external sources [1].
|  Ralf> * import one or more of these defines from other packages' headers.
| 
| This is really an Autoconf issue: that's AC_INIT which defines
| these symbols since 2.52g (prior versions don't do this).
| 
| Automake's no-define applies only to the symbols that Automake
| defines (PACKAGE & VERSION).  It can't undefine symbols defined
| elsewhere.

Correct.  Thanks Alexandre for bringing this back to where it belongs.

I have a preliminary question: how come these packages have no problem
with HAVE_FOO clashes?  How do they solve the very same issue in other
cases?