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

[Stepan Kasal]

Hello,

On Thu, Oct 20, 2005 at 11:31:13AM +0200, Ralf Wildenhues wrote:
> > Actually, I'm afraid you broke rule #2:
> >   Don't ever optimize.
> 
> Where does this rule come from?

1) Don't optimize.
2) Don't ever optimize.
3) (For experts only.) Under any circumstances, do not optimize.

> > (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, [...]

Sure, it was just a joke; I hoped you knew a variant of the joke above.

> If wanted, I can produce detailed proofs; I've done similarly before.

I don't think it's needed, I don't want to bother you with this.

> The AM_SUBST_NOMAKE is an almost trivial optimization which, in one
> specific example at least, makes a huge difference.

I think that AM_SUBST_NOMAKE for the *_TRUE and *_FALSE substs is an
excellent idea.

I suggested:

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

I'm afraid I haven't described the idea correctly.

This was meant as an optimization of automake, which would be totally
transparent to the user.  Automake would collect all the AC_SUBSTed variables,
as usual.  But instead of dumping the alphabetic list of "FOO = @FOO@" lines
to each of the generated Makefile.in, it would dump it only once, to
a file named "amvars.in".  Each Makefile.in would contain the following:

        @am__include@ @address@hidden(top_builddir)/address@hidden@

which would (for GNU make) result in:

        include $(top_builddir)/amvars

This way, the generated Makefile.ins would be much smaller, config.status
would run faster, and everyone would be happy.

Is this rough description clean now?

If yes, let me continue with a more detailed (and possibly confusing)
discussion:

1) What if the make doesn't support any form of "include"?

Automake currently uses @am__include@ for dependency tracking.  If the
"include" feature is not available, am__include is set to #.

This is not suitable for us.  If the make doesn't have "include",
config.status has to replace the include line with the whole contents
of file amvars.
(Yes, this would be slow, but it can happen only on legacy systems.
We don't have to bother with speed on rarely used systems.)

2) What if a Makefile.am redefines some of the AC_SUBSTed variables?

I thought previously that makefile cannot contain:
        FOO = this
        ...
        FOO = that
ie. two values for the same make variable.  If that were true, it would
complicate things.

Fortunately, it seems now that this was only a superstition.
So it is enough if we include the amvars file at the top of the
generated Makefile.

To sum up, this seems doable.
Ralf, are you willing to do some Perl hacking in automake.in?  ;-)

Have a nice day,
        Stepan Kasal