Re: only set variables in some Makefile.in's

[Ralf Wildenhues]

Hi Stepan,

Thank you for your insightful comments!

* Stepan Kasal wrote on Thu, Oct 20, 2005 at 09:30:37AM CEST:
> On Thu, Oct 20, 2005 at 09:03:19AM +0200, Ralf Wildenhues wrote:
> > How about allowing the user a little finer-grained choice of where
> > Makefile variables are needed, as in:
> ...
> > @item AM_SUBST_SET_IN(PATH..., VARIABLE, [VALUE])
> 
> I don't think it's worth it.
> Actually, I'm afraid you broke rule #2:
>   Don't ever optimize.

Where does this rule come from?

The `common rules' (whatever common means here) about optimization I
know are roughly:
 1) Don't optimize.
 2) Don't optimize yet.
 3) Measure when optimizing.  Measure again.

I'll add a reference to another one[1] (sorry for the quoted
capitalization):
| DO NOT ADD ALGORITHMS WITH QUADRATIC OR WORSE BEHAVIOR, EVER.

Now while this refers to GCC specifically, it does not mean other tools'
execution time used during software construction don't influence work
flow and usability.

And another one, which stems from a maths background (own wording):
| Don't bother much with improving a constant factor, unless the
| underlying algorithm already has optimal complexity and/or the factor
| dominates the overall space/time.

> (Perhaps even AM_SUBST_NOMAKE was breaking that rule?)

Stepan, with all humble respect, I believe I have followed above rules.

I've been using autotools for a few years now, I know real-world
examples of packages having configure scripts several megabytes large,
hundreds of Makefiles, hundreds of substitutions.  The tendency to
combine packages to larger packages increases the nonlinear effect.
The bootstrap procedure of the packages clearly _shows_ the quadratic
effects, with execution times of several minutes on fast machines even,
not to speak of less well equipped ones.

If wanted, I can produce detailed proofs; I've done similarly before.
The AM_SUBST_NOMAKE is an almost trivial optimization which, in one
specific example at least, makes a huge difference.  Surely it's
debatable whether it's the _right_ solution for the given problem.

> If you wanted to optimize, you could put all variable assignments to one
> big file, which would then get included by ll the Makefiles.

Yes.  This is one possibility.  There are, however, trade-offs to make:

One Makefile with special AM_*FLAGS setting might be smaller (and more
efficient!) than its merge into the parent Makefile, resulting in per-
object build rules.  Just one example, but the per-target bloat is IME 
the worst factor.

Surely it might also be merely inconvenient or difficult for the user to
combine Makefiles.

> You just have to solve several minor problems:
> 1) if make doesn't support any form of `include', you have to AC_SUBST
> the file with variables.
> 2) if a variable is redefined in any of the makefiles, it should be
> removed from the common set.

Hmm.  Yes, this may prove to be a better solution.  Need to think about
it, but a couple of short notes:
- It does not improve `make' execution time, but my impression so far
was that that hasn't been a limiting factor yet.
- Surely less-equipped `make' implementations lose out a bit.  Oh well.
- The combination of some user setups and rule (2) may cause the common
set to get smaller with increasing package size.  OTOH:
- Why is rule (2) necessary in the first place?  If we can guarantee the
common-set-file to be included/expanded before the overrides (which in
turn come before any rules), I don't see a problem.  Automake's error
reporting with locations might have to be adjusted?

> Point 1) is trivial, point 2) requires some perl programming, I'm afraid.
> And 2) would probably practically disable the
>       automake subdir/Makefile
> ie. you would have to call automake to rebuild all Makefile.in's.

I don't see yet why we'd have to give this up, see last note above.

> I don't think it's worth it, but if you are willing to write a patch,
> and if Alexandre won't reject it, why not?

Let's wait for more input first.

Cheers,
Ralf

[1] http://gcc.gnu.org/wiki/Speedup%20areas