Re: Yet another bootstrap failure: Required feature `esh-groups' was not provided

[Alan Mackenzie]

Hi, Eli!

On Fri, Jun 06, 2008 at 11:41:36PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 6 Jun 2008 20:35:41 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: address@hidden

> > Our makefile system is broken.  The whole point of the make utility
> > is to build software automatically, so that hackers don't need to
> > waste their time messing with arcane minutiae.  Is it really to much
> > to expect to be able to type

> >     % ./configure <params>; make some-target

> > and have the software build (modulo errors in the files.{c,el}?

> This does work, just not in an arbitrary CVS-updated sandbox.  That
> is, in a release tarball, the configure behaves exactly as you want it
> to.

That's not the point here.  Why shouldn't make be able to work in an
arbitrary CVS setup?  I think it could, that it should, just that it
doesn't at the moment.  I can't see any feature of Emacs which renders
the make paradigm (putting dependencies into Makefile and checking
timestamps) non functional.  Our Makefiles simply don't record the
dependencies properly.

> Sorry, Alan, but your expectations are too high.  AFAIK, a bootstrap
> build is guaranteed to work only in a fresh CVS checkout.  It is not
> guaranteed to work in a sandbox littered by stale files.

OK, I didn't know that.  So a workaround for me could be to copy all
source files to a temporary directory structure, build there with make
bootstrap, then copy the resulting files back to my main directory.

"Stale files" means, for example, .elc files whose source hasn't changed,
but use defuns at byte-compilation time or macros which have changed.

> I agree that it would be great to have more, but it's a lot of work,
> and the results cannot be reasonably tested in practice, since the
> number of different ways you can screw up your sandbox is infinite.

Agree, agree, disagree, agree.  It may not be possible for a build to
work all the time, but it could be made to work nearly all the time.  I
think; I hope.

> People who regularly update from CVS trunk are expected to be able to
> tinker with their files, and have enough energy for that.

:-)  I conjecture that it's updating sporadically rather than continually
that causes the pain.

> > Just as a matter of interest, in the last few months on emacs-devel
> > there have been approximately these numbers of threads complaining
> > about Emacs CVS not building:

> > May:       7
> > April:     9
> > March:     9
> > February:  2

> That's expected, in a trunk that is actively developed by many
> contributors at once.

?????  Do you know whether it happens in other projects with ~20 active
developers?

> > Whatever the reason, this is a horrendous time sink.  Failure to
> > build the CVS head should essentially _never_ happen - possibly once
> > or twice a year at most.

> Sorry, but it's hopelessly unrealistic to request that.  Given the
> number of different platforms we support, it is impractical even to
> request that any given change will compile on all of them, let alone
> build without a hitch.

OK.  I have an utterly standard, if somewhat old, GNU/Linux box, probably
the most popular setup.  I think it's reasonable to expect the trunk to
build on my box nearly all the time.  Possibly on w32, too.

> > Recently, I proposed installing a tool on savannah which would
> > trigger a test build every time source files were committed.  The
> > proposal didn't meet with much enthusiasm.

> Well, how about volunteering to do it, then?  It obviously bugs you
> enough to make you a motivated individual.

Yes.  I think I will try to enhance Makefile.in to record more
dependencies.  

-- 
Alan Mackenzie (Nuremberg, Germany).