Re: Speeding up the bootstrap build - a quick hack.

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Tue, Jan 18, 2022 at 15:48:23 -0500, Stefan Monnier wrote:
> >> >> > -.PHONY: compile-first compile-main compile compile-always
> >> >> > +.PHONY: compile-zeroth compile-first compile-main compile compile-always

> >> >> > -compile-first: $(COMPILE_FIRST)
> >> >> > +compile-zeroth: $(COMPILE_ZEROTH)
> >> >> > +compile-first: compile-zeroth $(COMPILE_FIRST)

> >> >> Is this necessary, or is it just helpful to debug the Makefile?

> >> > I'm not sure.  I'm a little confused, still.

> > It seems to be necessary.  At any rate, changing the mix slightly gave
> > rise to unwanted results.  In particular...

> >> At least I can't see why `compile-first` should need to depend on
> >> `compile-zeroth` since the

> >>     %.elc: %.el $(COMPILE_ZEROTH)

> > If I change that line to

> >     %.elc: %.el compile-zeroth

> > , then Emacs builds, but redundantly ELC's all the .el files which are
> > preloaded, taking 15 seconds longer to do so.  I don't understand why
> > this happens.

> > Even more notably, if I eliminate compile-zeroth, putting in instead
> > $(COMPILE_ZEROTH) everywhere needed, then make creates and deletes the
> > ..elc0 files four times, and also redundantly runs ELC on the preloaded
> > ..el files, despite them already being .eln's.  This run took 2½ minutes
> > longer than expected, too.  I don't understand why all that happened,
> > either.

> But what if you don't define `compile-zeroth`, and you keep:

>     compile-first: $(COMPILE_FIRST)

> and

>     %.elc: %.el $(COMPILE_ZEROTH)

> ?

I think that is what I have just tried again.  The results are as in my
paragraph above beginning "Even more notably, ....".

I don't understand at all what's happening.  Maybe it's something to do
with compile-zeroth being declared .PHONY.  It also might have to do with
make somehow regarding *.elc0 as "intermediate files", and is thus "safe"
to delete them (four times deleted in total).

> >> rule should already give the same result.  So I'd suggest you drop
> >> this part of the patch and see if that causes any kind of trouble.
> > As above, it caused all sorts of trouble.

> Maybe I'm confused but IIUC none of what you tried corresponds to just
> not using the above hunk.

I think I'm confused.  make isn't a simple program.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).