Re: 38-doc-ac-init.patch

[Ralf Corsepius]

Am 20 Aug 2001 19:51:33 +0200 schrieb 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.
Here, our opinions apparently differ. IMO, this requirement is at least
"very limiting" from the user's perspective and furthermore probably is
a strong indication of a fundamental deficiency in the working
principles currently being used.

I already mentioned a couple of cases before on the autoconf-list, but
...

.. I guess, I need to write some examples ..

> | 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.
Well, I don't think we misunderstand. 

> 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?
Yes, the configure.ins (Still using autoconf-2.13, currently trying to
be compatible to autoconf-2.5[0-2]; > 2.52 has not yet been tried; plans
are to switch to autoconf-2.52, soon) share a lot of common stuff via a
common set of autoconf/aclocal macros.

> | 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.
I don't understand, what will not work? It has worked until now, even
with autoconf-2.52.

> | This is a stripped fragment of the macro being used:
> | 
> | AC_DEFUN([XXX_TOP],
> [.]
> 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.
OK, for the moment this is an acceptable compromise.

> 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?
Somewhat oversimplied, yes. In fact it is one large package, consisting
of several subpackages, with some of them being useless (and therefore
optional) in certain situations and with users being allowed to add
further packages to it (Until now, without having to edit the general
parts of the package framework).

[Basically, the situation is comparable to the so-called "Cygnus/GNU"
source-tree, which can (theoretically) be configured as a whole or with
subdirectories omited.]

> But when you ship them, you do run autoconf etc. on
> the whole suite, don't you?
Yes, in this case incrementing all version numbers by modifying all
configure.ins would not give much difference.

But it would result into a significant increase in the size of
incremental patches. Until now, unless a configure.in has actually been
changed, the configure.ins/configure scripts etc.[1] need not to be
updated, therefore can be omited from diffs, consequently giving much
smaller diffs than they were if using hard.coded version numbers.

Ralf

[1] 149 configure.ins, 988 Makefile.ams, changing all configure.ins
would probably result into diffs which are several MB large.