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