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

[Eli Zaretskii]

> Date: Sat, 7 Jun 2008 09:50:24 +0000
> Cc: address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > 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?

Because development adds and removes files (which doesn't happen with
releases), and stale files can get in the way in unpredictable ways.

> Our Makefiles simply don't record the dependencies properly.

That might be one reason for the problems, but it isn't the only one.
And if you are talking about Lisp files, their dependencies are not
easy to find out, due to lots of macros implicitly imported at compile
time via `require'.

Perhaps we should first improve our infrastructure: how about a switch
to Emacs, like the -MD switch to GCC, that would cause it to generate
a Make include file with dependencies as a side effect of byte
compilation?  Without help from the byte compiler, I'd consider any
additional dependencies for Lisp files an unjustified maintenance
burden, because those dependencies will need to be updated any time
some `require' line somewhere is added, deleted, or modified.

> > 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.

It's fruitless to argue with hopes, so I won't.

> > 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.

"Regularly" doesn't mean every day; it could mean once a week or once
in a fortnight.

> > > 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?

None of the projects I'm involved with that have something similar to
"bootstrap" use the kind of ``fire at will'' commit policy we use in
Emacs.  Those other projects all have some kind of mandatory
review-before-commit policy for all but a few extremely trusted
developers.  At peer review time, problems can be detected before they
do any harm.

> 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.

What is a ``standard GNU/Linux box''?  Is it 32-bit or 64-bit?  What
kernel version do you use, and what version of glibc?  What compiler
version?

Any one of the above factors, and perhaps more, could cause a change
that compiles on the contributor's machine not to compile on yours.

> > > 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.  

Thank you.