Re: 38-doc-ac-init.patch

[Akim Demaille]

| > So that it can be traced.
| Dooh, then I have to reiterate what I said several times before with
| regard to AC_CONFIG_SUBDIRS. 

Again, I don't understand the problem with the latter: we need to know
the list of all the possible values statically, not that actually used.

| There are circumstances, where you can't avoid variables. So if tracing
| can not handle variables in general, autoconf's tracing mechanism has a
| fundamental problem.

We might misunderstand each other.  Just don't use AC_INIT with
package and version, and you're done.  Just don't expect Automake to
help you.  But there is no obligation to use this.


| > Why don't you have a m4_include(my_version.m4)?
| > 
| Two reasons:
| 
| 1) autoconf-2.13 backward compatibility
| 2) I have not known about m4_include, before.

:)

Well, forgot about m4_include, just have a version.m4 under aclocal.m4
which defines the common set of values.  Do your configure.ac share
something?


| This is an excerpt of what is actually used:
| 
| We grep for a string and set a shell variable from inside an autoconf
| macro between AC_INIT and AC_INIT_AUTOMAKE.

If you want to use Automake, I'm afraid it won't be able to work.

| This is a stripped fragment of the macro being used:
| 
| AC_DEFUN([XXX_TOP],
| [
| XXX_TOPdir=[$1]
| AC_MSG_CHECKING([for XXX Version])
| if test -r "${srcdir}/${XXX_TOPdir}/VERSION"; then
| XXX_VERSION=`grep 'XXX Version' ${srcdir}/${XXX_TOPdir}/VERSION | \
| sed -e 's%XXX[[       ]]*Version[[    ]]*\(.*\)[[     ]]*%\1%g'`
| else
| AC_MSG_ERROR(Unable to find ${XXX_TOPdir}/VERSION)
| fi
| if test -z "$XXX_VERSION"; then
| AC_MSG_ERROR(Unable to determine version)
| fi
| AC_MSG_RESULT($XXX_VERSION)
| ])
| 
| 
| Then, configure.ins carry a fragment similar to this:
| 
| AC_INIT(file)
| XXX_TOP(../../..)
| AC_CONFIG_AUX_DIR(../../..)
| AM_INIT_AUTOMAKE(package,$XXX_VERSION,no)
| ...
| 
| Note 1: PACKAGE and VERSION has not been required by AC_INIT until now,
| and setting them before AC_INIT did not work (autoconf ignored them).

It still does.  It's only your configure --help and worse yet,
configure --help-recursive that must look weird.

As for backward compatibility, I think my proposal is OK.

Hm... Let me understand some more: you have a set of independent
packages, but they sometimes are all shipped with the same version
number, right?  But when you ship them, you do run autoconf etc. on
the whole suite, don't you?