Re: AM_SUBST_IGNORE = AC_SUBST without Makefile variable definition

[Ralf Wildenhues]

Hi Stepan,

* Stepan Kasal wrote on Wed, Oct 19, 2005 at 07:28:14AM CEST:
> On Tue, Oct 18, 2005 at 01:24:14PM +0200, Ralf Wildenhues wrote:
> > 
> > I don't see why the solution to the problem of not substituting certain
> > variables is dependent on the problem of how to handle multiline
> > substitutions?
> 
> I wrote an answer yesterday, but by mistake I posted it to Ralf only.
> In short, I'm not sure that the feature is necessary.
> 
> Ralf wrote me a very nice explanation, which convinced me.
> In short, it is needed as the solution for PR/477.

See below for the long version.

> I still think it should be implemented in Autoconf, see the patch below.
> 
> Would you like it this way?

I guess that's less intrusive.  Surely, short-term it will introduce
another version dependency of Automake on Autoconf.  Not my call to
make.  :)

> (A nice side effect: AC_SUBST_NOTRACE would work even if used with
> previous versions of Automake.)

It would be really nice if behavior could be selected more fine-tuned by
the user.  For example, I believe the flattening necessary for multiline
outputs in Makefile could be explicitly selected by AC_SUBST_FLATTEN.
Also, I believe the flattening can be achieved rather easily when done
in shell rather than in sed.  Esp. if time-consuming, its execution
should not punish packages not making use of the feature.

By the way, aren't there other tools that trace AC_SUBST?  Any issues
with above patch for them?


Now to the aforementioned (overhauled) explanation:  Short version:

Stepan's previous suggestion did not address my original complaint:
superlinear growth hurts.  :)

Just to show how big an impact this can make on a real-world package:
Removing the
  SOME_CONDITIONAL_TRUE = @SOME_CONDITIONAL_TRUE@
  SOME_CONDITIONAL_FALSE = @SOME_CONDITIONAL_FALSE@
from Makefile.in's can make the gzip-9'ed tarball 600KB smaller.


Long version:

The number of AC_SUBSTed variables tends to grow, let's assume linearly,
with package size, where package size is a rather not-well-defined
quantity.

The number of Automake conditionals tends to grow at least linearly with
package size (the fact that logical OR has to be emulated with another
conditional may add to this).

OTOH, the number of actual *uses* of either variables or conditionals in
Makefiles tends to be
- a small constant (O(1)) for most of them
- linearly many for a small number (O(1)) of them
*even if* above growth is observed.

The number of Makefile.in's tends to grow linearly with size in most but
not all packages.

Thus, we have quadratically scaling baggage we don't actually need.
This possibility alone should call for a macro to declare variables that
Autoconf should substitute but Automake should not *set*.

We have several ways out:
- reduce the number of Makefile.in's
- reduce the amount of Automake-set variables

Both help, but both have limited applicability.  Not setting the
variables created by AM_CONDITIONAL is about the very cheapest way to
attack this issue.


Side notes:
- I actually benchmarked the Autoconf code doing the substitutions,
as it's in such a hot code path.  I was surprised how well-tuned it is.
One has to note that common `sed' implementations (e.g., GNU sed) all
have execution times that depend at least linearly on the number of s///
commands given, which is not a technical necessity, by the way.
The _AC_SED_CMD_LIMIT of 100 (set in autoconf/lib/autoconf/status.m4)
is not only a good choice for portability limits, but also for fastest
execution on a typical GNU/Linux system.  :)
Also, the code in CVS Autoconf, while more general (multiline output!),
turned out to be a bit faster than the 2.59 code even.

- There are more sources of superlinear growth in some Autotools usage
patterns, see [1] for a completely different example.  If we can eliminate
the ones that happen to be relevant in practice, the tools are much more
useful.

Cheers, and thanks for reading this far,
Ralf

[1] http://lists.gnu.org/archive/html/libtool-patches/2005-05/msg00153.html