[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alan Mackenzie
Subject: Re: Yet another bootstrap failure: Required feature `esh-groups' was not provided
Date: Sat, 7 Jun 2008 20:08:21 +0000
User-agent: Mutt/1.5.9i

Hi, Eli!

On Sat, Jun 07, 2008 at 03:19:31PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 7 Jun 2008 09:50:24 +0000
> > Cc: address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

[ .... ]

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

It can't be that difficult; lisp is designed for this type of

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

The dependencies absolutely must be generated automatically.  Whether
this should be done by the byte-compiler or a separate script isn't clear
(yet).  Such a separate script could probably be run in temacs, creating
the dependencies very early in the build process.

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

Oh, you cynical person.  ;-)

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

"Sporadically", for me, means once a month or once every two months.

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

One kind of "peer review" we could do is doing a build test as part of
the commission process.  This might be a bit heavy on server CPU time.

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

For what it's worth:
Linux acm 2.6.8 #7 Wed May 23 18:12:53 BST 2007 i686 GNU/Linux.
glibc: don't know, how do you display the version number?
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

I can't honestly see that it's worth that much.  Won't Emacs compile with
pretty much any Linux version, any GCC and any GLIBC?

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]