unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rgm@gnu.org, emacs-devel@gnu.org
Subject: Re: Yet another bootstrap failure: Required feature `esh-groups'	was	not provided
Date: Sat, 7 Jun 2008 20:08:21 +0000	[thread overview]
Message-ID: <20080607200821.GI1812@muc.de> (raw)
In-Reply-To: <uskvpmo8c.fsf@gnu.org>

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: rgm@gnu.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

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

> 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:
32-bit;
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	other threads:[~2008-06-07 20:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-06 15:59 Yet another bootstrap failure: Required feature `esh-groups' was not provided Alan Mackenzie
2008-06-06 17:22 ` Glenn Morris
2008-06-06 18:23   ` Dan Nicolaescu
2008-06-06 19:27     ` Stefan Monnier
2008-06-06 20:35   ` Alan Mackenzie
2008-06-06 20:41     ` Eli Zaretskii
2008-06-07  2:53       ` Glenn Morris
2008-06-07  9:07         ` Alan Mackenzie
2008-06-07 19:49           ` Glenn Morris
2008-06-07  9:50       ` Alan Mackenzie
2008-06-07 12:19         ` Eli Zaretskii
2008-06-07 20:08           ` Alan Mackenzie [this message]
2008-06-07 22:17             ` Stephen J. Turnbull
2008-06-07 22:29               ` Romain Francoise
2008-06-08  2:58                 ` Stefan Monnier
2008-06-08  2:56             ` Build-time dependencies Stefan Monnier
2008-06-08 19:03               ` Glenn Morris
2008-06-08 19:25                 ` Eli Zaretskii
2008-06-08 19:31                   ` David Kastrup
2008-06-09  1:44                   ` Glenn Morris
2008-06-09  1:49                     ` Glenn Morris
2008-06-09  8:26                       ` Eli Zaretskii
2008-06-09 15:32                         ` Ted Zlatanov
2008-06-09 15:32                           ` David Kastrup
2008-06-09 10:30                       ` Robert J. Chassell
2008-06-09 17:22                       ` Richard M Stallman
2008-06-09 18:15                         ` Glenn Morris
2008-06-09 19:47                           ` Miles Bader
2008-06-09 19:53                             ` Glenn Morris
2008-06-10 18:22                               ` Ted Zlatanov
2008-06-10 18:54                                 ` Stefan Monnier
2008-06-09  4:37                     ` Stephen J. Turnbull
2008-06-09  1:51                   ` Stefan Monnier
2008-06-09 16:41                   ` Alan Mackenzie
2008-06-07 22:32           ` Yet another bootstrap failure: Required feature `esh-groups' was not provided Stephen J. Turnbull
2008-06-07  2:51     ` Glenn Morris
2008-06-07  8:58       ` Alan Mackenzie
2008-06-06 23:51 ` Vinicius Jose Latorre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080607200821.GI1812@muc.de \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rgm@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).