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

[Ralf Corsepius]

Am Mon, 2002-02-04 um 10.31 schrieb 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?
There are two cases:

a) HAVE_FOO's are supposed to be identical, if a package defines them
itself. If they aren't, the configuration is inconsistent and is
supposed to boil out.

b) They initially are undefined, and later defined by indirectly
including the other packages' config-headers.


But I think, the actual cause for this issue is something different:

1) Autoconf considers config-headers to be valid within the scope of a
subdirectory-hierarchy a configure is responsible and to be a means to
store detected values.

2) AC_DEFINE etc. allows users to use config-headers as a general means
to store any (ie. user-supplied, detected and derived) configuration
values.

3) AM_INIT_AUTOMAKE([no-define]) allows config-headers to be exported,
ie. to export and thereby globally store configuration information.

IMO, users, using AM_INIT_AUTOMAKE([no-define]), normally are not
interested in 1), however actually want to have a means to export very
few essential package configuration details to user-space.

Example:

One case, I have encountered this issue, is a library of X11-widgets,
which can alternatively be compiled with or without Motif.

One of this library's public header file (The widget base-class)
contains things like these:

[..]
/* include config-header */
#include <X11/Xrc/config.h>

/* Full instance record declaration */
typedef struct _XrcXXXRec {
  CorePart              core;
#if HAVE_MOTIF
  XmPrimitivePart       primitve ;
#endif
  XrcXXXPart            xxx;
} XrcXXXRec;
[..]

I.e. the header exposes the internal detail of the library being
alternatively compilable w/ and w/o Motif to the user, though the
library can only be compiled in one variant at a time.

Of cause, there are other means to implement this, ...
(AC_SUBST + AC_CONFIG_FILES(header.h:header.h.in), 
generating the header from AC_CONFIG_COMMANDS,
generating the header from inside a Makefile.am,
running a build-tool, etc.)

=> IMO, the actual cause of this issue is the lack of an infrastructure
similar to AC_DEFINE and AC|M_CONFIG_HEADER to explicitly allow users to
export configuration values.

Ralf