Re: Emacs-devel Digest, Vol 52, Issue 61

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

emacs-devel-request@gnu.org <emacs-devel-request@gnu.org>:
> > > 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.

I agree with this complaint, and I'm getting extremely frustrated.  I
have been unable to work on vc.el for about *two weeks* now because
the recommended "make maintainer-clean; configure; make bootstrap"
consistently fails with this:

make[3]: *** No rule to make target `/home/esr/cvs/emacs/lisp/nxml/nxml-enc.elc', needed by `compile-main'.  Stop.

This is on stock Ubuntu 8.04.  Whoever said expecting builds in CVS to
work consistently was "hopelessly unrealistic" is simply revealing that the 
Emacs system is broken as designed.  Maybe this is a *reason* we have so 
few developers?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Alan Mackenzie]

Hi, Eric!

On Sat, Jun 07, 2008 at 09:20:37AM -0400, Eric S. Raymond wrote:
> emacs-devel-request@gnu.org <emacs-devel-request@gnu.org>:
> > > > 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.

> I agree with this complaint, and I'm getting extremely frustrated.  I
> have been unable to work on vc.el for about *two weeks* now because the
> recommended "make maintainer-clean; configure; make bootstrap"
> consistently fails with this:

> make[3]: *** No rule to make target `/home/esr/cvs/emacs/lisp/nxml/nxml-enc.elc', needed by `compile-main'.  Stop.

This is precisely "my" error message too.  I've had a wee look at it, and
my directory tree doesn't have the directory nxml, despite my just having
done a `cvs update'.  nxml is a new directory in the Emacs trunk (?about
4 weeks old?).  Shouldn't `cvs update' download this new directory?

[`cvs --version' gives: Concurrent Versions System (CVS) 1.12.9
(client/server)]

> This is on stock Ubuntu 8.04.  Whoever said expecting builds in CVS to
> work consistently was "hopelessly unrealistic" is simply revealing that
> the Emacs system is broken as designed.  Maybe this is a *reason* we
> have so few developers?

That thought had occurred to me too.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs-devel Digest, Vol 52, Issue 61

[Juanma Barranquero]

On Sat, Jun 7, 2008 at 16:14, Alan Mackenzie <acm@muc.de> wrote:

> I've had a wee look at it, and
> my directory tree doesn't have the directory nxml, despite my just having
> done a `cvs update'.  nxml is a new directory in the Emacs trunk (?about
> 4 weeks old?).  Shouldn't `cvs update' download this new directory?

Does "cvs update -d" create the lisp/nxml dir?

   Juanma

Re: Emacs-devel Digest, Vol 52, Issue 61

[Alan Mackenzie]

Hi, Juanma

On Sat, Jun 07, 2008 at 04:07:03PM +0200, Juanma Barranquero wrote:
> On Sat, Jun 7, 2008 at 16:14, Alan Mackenzie <acm@muc.de> wrote:

> > I've had a wee look at it, and my directory tree doesn't have the
> > directory nxml, despite my just having done a `cvs update'.  nxml is
> > a new directory in the Emacs trunk (?about 4 weeks old?).  Shouldn't
> > `cvs update' download this new directory?

> Does "cvs update -d" create the lisp/nxml dir?
 
Yes, indeed!  And my trunk copy has built.  Calloo, callay!

>    Juanma

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs-devel Digest, Vol 52, Issue 61

[Juanma Barranquero]

> Yes, indeed!  And my trunk copy has built.

Perhaps you could put

update -dP

into your ~/.cvsrc file.

   Juanma

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eli Zaretskii]

> Date: Sat, 7 Jun 2008 15:24:08 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: "Eric S. Raymond" <esr@thyrsus.com>, emacs-devel@gnu.org
> 
> > Does "cvs update -d" create the lisp/nxml dir?
>  
> Yes, indeed!  And my trunk copy has built.  Calloo, callay!

So the rant about broken Emacs build machinery boiled down to a
cockpit error invoking CVS?

Re: Emacs-devel Digest, Vol 52, Issue 61

[Alan Mackenzie]

On Sat, Jun 07, 2008 at 07:46:44PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 7 Jun 2008 15:24:08 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: "Eric S. Raymond" <esr@thyrsus.com>, emacs-devel@gnu.org

[ .... ]

> So the rant about broken Emacs build machinery boiled down to a
> cockpit error invoking CVS?

Not quite.  It was the combination of cockpit error with a general
expectation of failure of the build.  Without the latter, I (and
presumably Eric too) would have sought out the actual failure more
assiduously.

Cockpit errors will continue to happen.  Therefore the expectation of
failure should be reversed.  I'll be looking to see how to do this.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
> Not quite.  It was the combination of cockpit error with a general
> expectation of failure of the build.  Without the latter, I (and
> presumably Eric too) would have sought out the actual failure more
> assiduously.

It's true.  I'd seen the build randomly break so often that I didn't
dig into this one as vigorously as I might have.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Glenn Morris]

Alan Mackenzie wrote:

> Not quite.  It was the combination of cockpit error with a general
> expectation of failure of the build.

I'm a little pissed off.

It's not my fault if people don't know how to use CVS, don't know how
to build Emacs, or don't know how to search a list archive.

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Glenn Morris <rgm@gnu.org>:
> It's not my fault if people don't know how to use CVS, don't know how
> to build Emacs, or don't know how to search a list archive.

I don't think anyone is interested in finding fault with you, or
with anyone else.

This project has a lot of broken, crappy toolkit associated with it --
stuff that looked cutting edge 15 or 20 years ago but is just painful
now.  Replacing it is will be a big job.  The first step to replacing
it is developing the will to do so, and the first step to *that* is
understanding what the hidden costs of the crappiness are.  We've
tripped over some of them in this thread.

Um, what else do you suppose the fact that I half-expect the build to be
broken on any given day means?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eli Zaretskii]

> Date: Sat, 7 Jun 2008 16:10:57 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Alan Mackenzie <acm@muc.de>, Eli Zaretskii <eliz@gnu.org>,
> 	lekktu@gmail.com, emacs-devel@gnu.org
> 
> Um, what else do you suppose the fact that I half-expect the build to be
> broken on any given day means?

That you are prejudiced beyond all reason?

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Um, what else do you suppose the fact that I half-expect the build to be
> > broken on any given day means?
> 
> That you are prejudiced beyond all reason?

Not prejudiced.  Experienced.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Stefan Monnier]

Can we stop this silly thread and get back to our regular hacking.
Fingerpointing is not nearly as much fun as people seem to think it is,
and in the end all we get is mutual distrust.


        Stefan

Re: Emacs-devel Digest, Vol 52, Issue 61

[Alan Mackenzie]

On Sat, Jun 07, 2008 at 04:10:57PM -0400, Eric S. Raymond wrote:

> Um, what else do you suppose the fact that I half-expect the build to
> be broken on any given day means?

That you do a `cvs update' with dread, not knowing how many unproductive
hours lie ahead before you can get back to doing real work on Emacs.

That you will thus procrastinate updating Emacs, and suffer
dissatisfaction from not doing the Right Thing.

That working on Emacs is less fun than it might be, and that this has
thus gone way down on your personal hacking priority list.

Am I right?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Alan Mackenzie <acm@muc.de>:
> On Sat, Jun 07, 2008 at 04:10:57PM -0400, Eric S. Raymond wrote:
> 
> > Um, what else do you suppose the fact that I half-expect the build to
> > be broken on any given day means?
> 
> That you do a `cvs update' with dread, not knowing how many unproductive
> hours lie ahead before you can get back to doing real work on Emacs.
> 
> That you will thus procrastinate updating Emacs, and suffer
> dissatisfaction from not doing the Right Thing.
> 
> That working on Emacs is less fun than it might be, and that this has
> thus gone way down on your personal hacking priority list.
> 
> Am I right?

Absolutely.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Richard M Stallman]

I think it would be nice if `make bootstrap' could decide
automatically whether it needs to build from source to recompile the
Lisp code.  Then people could use it every time, without a pain in the
neck which most of the time is unnecessary.  It could even be
renamed to `all'.

For instance, suppose `make bootstrap' recompiles all the Lisp code
only if bootstrap.elc is older than bootstrap.el.  Otherwise,
it could recompile the preloaded Lisp files and dump a second time
if any of them changed.

Re: Emacs-devel Digest, Vol 52, Issue 61

[Alan Mackenzie]

Hi, Glenn,

On Sat, Jun 07, 2008 at 03:53:38PM -0400, Glenn Morris wrote:
> Alan Mackenzie wrote:

> > Not quite.  It was the combination of cockpit error with a general
> > expectation of failure of the build.

> I'm a little pissed off.

To the extent that it's me to blame, sorry.

> It's not my fault if people don't know how to use CVS, don't know how
> to build Emacs, or don't know how to search a list archive.

No indeed.  However, now that I've learned a bit more about CVS, and a
bit more about building Emacs, things will be going more smoothly for me
at least from now on.  Thanks for pointing in the right direction in the
last few hours.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Date: Sat, 7 Jun 2008 15:24:08 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: "Eric S. Raymond" <esr@thyrsus.com>, emacs-devel@gnu.org
> > 
> > > Does "cvs update -d" create the lisp/nxml dir?
> >  
> > Yes, indeed!  And my trunk copy has built.  Calloo, callay!
> 
> So the rant about broken Emacs build machinery boiled down to a
> cockpit error invoking CVS?

Well, that's one way to put it.  An equally valid analysis would
be that -d ought to be the default rather than an option I've
never heard of before, and CVS is broken as designed.  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Eli Zaretskii <eliz@gnu.org>:
>> > Date: Sat, 7 Jun 2008 15:24:08 +0000
>> > From: Alan Mackenzie <acm@muc.de>
>> > Cc: "Eric S. Raymond" <esr@thyrsus.com>, emacs-devel@gnu.org
>> > 
>> > > Does "cvs update -d" create the lisp/nxml dir?
>> >  
>> > Yes, indeed!  And my trunk copy has built.  Calloo, callay!
>> 
>> So the rant about broken Emacs build machinery boiled down to a
>> cockpit error invoking CVS?
>
> Well, that's one way to put it.  An equally valid analysis would
> be that -d ought to be the default rather than an option I've
> never heard of before, and CVS is broken as designed.

What else is news?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs-devel Digest, Vol 52, Issue 61

[Nick Roberts]

 > Well, that's one way to put it.  An equally valid analysis would
 > be that -d ought to be the default rather than an option I've
 > never heard of before, and CVS is broken as designed.  

I'm surprised that you've not heard of it because it's needed for updating from
a CVS repository each time a new directory is added.  In recent years, for
emacs that has mean't org, erc, gnus, mh-e...

I'm not sure that it should be the default because using it with repositories
which share source means that you pick up directories that you don't want, e.g.,
gdb shares with binutils and if you do:

cvs checkout gdb 'sourceware url'     i.e. the gdb module
cd gdb
cvs up -d

you get the binutils directory.

I think these are the quirks of VCses with which we have to become familiar.

I wonder how bzr handles new directories.  I'm sure it is better but, for me,
CVS has the advantage of feeling like an old friend.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs-devel Digest, Vol 52, Issue 61

[joakim]

Nick Roberts <nickrob@snap.net.nz> writes:

> I think these are the quirks of VCses with which we have to become familiar.
>
> I wonder how bzr handles new directories.  I'm sure it is better but, for me,
> CVS has the advantage of feeling like an old friend.

FWIW I've used bzr for emacs development recently and its pretty nice.
I keep a couple of branches in a shared repository synced from
http://bzr.notengoamigos.org/emacs/trunk/. Sometimes stuff happens that
I dont expect, but not too much.

-- 
Joakim Verona

Re: Emacs-devel Digest, Vol 52, Issue 61

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

> I wonder how bzr handles new directories.  I'm sure it is better but,
> for me, CVS has the advantage of feeling like an old friend.

With friends like that, who needs foes?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs-devel Digest, Vol 52, Issue 61

[Stefan Monnier]

> Well, that's one way to put it.  An equally valid analysis would
> be that -d ought to be the default rather than an option I've
> never heard of before, and CVS is broken as designed.

Also the -P.  I.e. alway use "update -dP".
I tend to assume that it's been common knowledge for something like a decade.


        Stefan

Re: Emacs-devel Digest, Vol 52, Issue 61

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Also the -P.  I.e. alway use "update -dP".
> I tend to assume that it's been common knowledge for something like a decade.

It seems quite hard to believe that anybody has followed Emacs CVS (or
any non-trivial project using CVS) for any length of time without using
those options...

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

use git, not cvs

[Jim Meyering]

"Eric S. Raymond" <esr@thyrsus.com> wrote:
...
> Well, that's one way to put it.  An equally valid analysis would
> be that -d ought to be the default rather than an option I've
> never heard of before, and CVS is broken as designed.

FYI, you can dump cvs and use git instead.
At least for emacs, you *can* do that.
I've been syncing a read-only git mirror to the CVS repository
for many months, so you can "checkout" a copy like this:

    git clone git://git.sv.gnu.org/emacs

The git repository should never be more than about 30-60
minutes behind the CVS one.

Preparing change-sets in git and pushing them back to
the cvs repository is not as painful as you might imagine,
thanks to the "git cvsexportcommit" command.  With a couple
of simple wrapper scripts and a little easy-to-manage local
policy, you might even come to find it "easy".

Re: use git, not cvs

[Juanma Barranquero]

On Tue, Jun 10, 2008 at 12:36, Jim Meyering <jim@meyering.net> wrote:

"git cvsexportcommit" does not work on the current MSYS/MinGW port of
git for Windows.

(Your git mirror is great, though, and I use it daily.)

   Juanma

Re: use git, not cvs

[Jim Meyering]

"Juanma Barranquero" <lekktu@gmail.com> wrote:
> On Tue, Jun 10, 2008 at 12:36, Jim Meyering <jim@meyering.net> wrote:
> "git cvsexportcommit" does not work on the current MSYS/MinGW port of
> git for Windows.

[to propagate your changes from a git mirror repo into the master cvs one]

I suppose you've reported it? or maybe that's a known limitation.

In a pinch, you can get by with just applying patches from git to
a CVS working tree, and then manually changing permissions and marking
files for addition/removal before doing the "cvs commit".

> (Your git mirror is great, though, and I use it daily.)

Thanks ;-)

Re: use git, not cvs

[Juanma Barranquero]

> I suppose you've reported it? or maybe that's a known limitation.

Known. Also, the MinGW port of git is extremely short on developers.

> In a pinch, you can get by with just applying patches from git to
> a CVS working tree, and then manually changing permissions and marking
> files for addition/removal before doing the "cvs commit".

Yes, I've done that a couple times.

   Juanma

Re: use git, not cvs

[Miles Bader]

Jim Meyering <jim@meyering.net> writes:
> The git repository should never be more than about 30-60
> minutes behind the CVS one.

Now if only people would stop committing multiple files in a big change
one-by-one... (it would make the git history a lot more readable)

-Miles

-- 
Helpmate, n. A wife, or bitter half.

Re: use git, not cvs

[Juanma Barranquero]

> Now if only people would stop committing multiple files in a big change
> one-by-one... (it would make the git history a lot more readable)

I don't think that's going to happen until we switch to Bazaar...

...How's that going, BTW? Didn't the last two point releases of Bazaar
include speed improvements prompted by Emacs?

   Juanma

Re: use git, not cvs

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> Now if only people would stop committing multiple files in a big change
>> one-by-one... (it would make the git history a lot more readable)
>
> I don't think that's going to happen until we switch to Bazaar...

Why not?  The more modern style of committing works perfectly well with
CVS, and improves the result of cvs-whatever gateways.  People could get
used to the newer practice now, and help the history be more rational,
whether in bzr, or in git.

-Miles

-- 
Friendship, n. A ship big enough to carry two in fair weather, but only one
in foul.

Re: use git, not cvs

[Juanma Barranquero]

> Why not?

Laziness.

> The more modern style of committing works perfectly well with
> CVS, and improves the result of cvs-whatever gateways.  People could get
> used to the newer practice now, and help the history be more rational,
> whether in bzr, or in git.

True.

  Juanma

Re: use git, not cvs

[Jim Meyering]

Miles Bader <miles.bader@necel.com> wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>> Now if only people would stop committing multiple files in a big change
>>> one-by-one... (it would make the git history a lot more readable)
>>
>> I don't think that's going to happen until we switch to Bazaar...
>
> Why not?  The more modern style of committing works perfectly well with
> CVS, and improves the result of cvs-whatever gateways.  People could get
> used to the newer practice now, and help the history be more rational,
> whether in bzr, or in git.

It's easy: just set policy and explain why it matters.
Of course, you'll have to send a polite message to the few
committers whose fingers forget.

It even easier once you've drunk the dVCS-flavored kool-aid
and realize e.g., that you can manipulate change sets using a
prefix of the one-line summary.

Re: use git, not cvs

[Jim Meyering]

Miles Bader <miles.bader@necel.com> wrote:
> Jim Meyering <jim@meyering.net> writes:
>> The git repository should never be more than about 30-60
>> minutes behind the CVS one.
>
> Now if only people would stop committing multiple files in a big change
> one-by-one... (it would make the git history a lot more readable)

Indeed.  To get an idea of what Miles is talking about,
compare emacs' gitweb summary with that of say, git itself:

  http://git.sv.gnu.org/gitweb/?p=emacs.git;a=summary
  http://repo.or.cz/w/git.git/

Consider how easy it would be to back out a single
change in git (where all files in a change set are committed at once)
while they're often distributed across two or more commits in emacs.

Has anyone tried to establish guidelines for this?
It's not just git, of course.  No matter what VCS emacs ends up
using, establishing a change-set oriented approach in cvs will make
the commit log a lot more useful.

Many projects encourage use of a single-line summary on
line #1 of the commit log, and then any prose/explanation,
followed by lines containing the usual ChangeLog-style entries.

Re: use git, not cvs

[Nick Roberts]

 > > Now if only people would stop committing multiple files in a big change
 > > one-by-one... (it would make the git history a lot more readable)
 > 
 > Indeed.  To get an idea of what Miles is talking about,
 > compare emacs' gitweb summary with that of say, git itself:
 > 
 >   http://git.sv.gnu.org/gitweb/?p=emacs.git;a=summary
 >   http://repo.or.cz/w/git.git/
 > 
 > Consider how easy it would be to back out a single
 > change in git (where all files in a change set are committed at once)
 > while they're often distributed across two or more commits in emacs.
 > 
 > Has anyone tried to establish guidelines for this?

Files are probably committed one-by-one because in the past that's how VC has
worked.  Maybe the new vc-dir interface will permit multiple files to be
committed as a single changeset.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: use git, not cvs

[Stefan Monnier]

>> The git repository should never be more than about 30-60
>> minutes behind the CVS one.
> Now if only people would stop committing multiple files in a big change
> one-by-one... (it would make the git history a lot more readable)

Yes, I encourage people to do that (I try to encourage myself to do
that as well, but old habits die hard).


        Stefan

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> On Sat, Jun 7, 2008 at 16:14, Alan Mackenzie <acm@muc.de> wrote:
> 
> > I've had a wee look at it, and
> > my directory tree doesn't have the directory nxml, despite my just having
> > done a `cvs update'.  nxml is a new directory in the Emacs trunk (?about
> > 4 weeks old?).  Shouldn't `cvs update' download this new directory?
> 
> Does "cvs update -d" create the lisp/nxml dir?

Trying...

...looks like it.  

Sounds like I need to write another documentation patch for the
INSTALL.CVS file.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Chong Yidong]

"Eric S. Raymond" <esr@thyrsus.com> writes:

>> 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.
>
> I agree with this complaint, and I'm getting extremely frustrated.  I
> have been unable to work on vc.el for about *two weeks* now because
> the recommended "make maintainer-clean; configure; make bootstrap"
> consistently fails with this:
>
> make[3]: *** No rule to make target `/home/esr/cvs/emacs/lisp/nxml/nxml-enc.elc', needed by `compile-main'.  Stop.
>
> This is on stock Ubuntu 8.04.  Whoever said expecting builds in CVS to
> work consistently was "hopelessly unrealistic" is simply revealing that the 
> Emacs system is broken as designed.  Maybe this is a *reason* we have so 
> few developers?

I haven't encountered this problem, and I'm using the same system.  Try
updating using `cvs up -Pd'.

Re: Emacs-devel Digest, Vol 52, Issue 61

[Miles Bader]

"Eric S. Raymond" <esr@thyrsus.com> writes:
> I have been unable to work on vc.el for about *two weeks* now because
> the recommended "make maintainer-clean; configure; make bootstrap"
> consistently fails with this:

It never occurred to you to _say something_ during those "two weeks"?

-Miles

-- 
Opposition, n. In politics the party that prevents the Goverment from running
amok by hamstringing it.

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Miles Bader <miles@gnu.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> > I have been unable to work on vc.el for about *two weeks* now because
> > the recommended "make maintainer-clean; configure; make bootstrap"
> > consistently fails with this:
> 
> It never occurred to you to _say something_ during those "two weeks"?

I have other things I'm working on.  I'd hit the wall, think "Usual breakage,
somebody will get it just like the previous times", and go do something else.

Two weeks of breakage got to be a bit much.  I was about ready to ship a loud
complaint when the build system thread happened.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eli Zaretskii]

> Date: Sat, 7 Jun 2008 15:41:40 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Miles Bader <miles@gnu.org>:
> > "Eric S. Raymond" <esr@thyrsus.com> writes:
> > > I have been unable to work on vc.el for about *two weeks* now because
> > > the recommended "make maintainer-clean; configure; make bootstrap"
> > > consistently fails with this:
> > 
> > It never occurred to you to _say something_ during those "two weeks"?
> 
> I have other things I'm working on.  I'd hit the wall, think "Usual breakage,
> somebody will get it just like the previous times", and go do something else.
> 
> Two weeks of breakage got to be a bit much.  I was about ready to ship a loud
> complaint when the build system thread happened.

In my experience, a bootstrap never remains broken for more than a few
hours.  If it isn't fixed in a day, I look for problems local to my
sandbox.

Re: Emacs-devel Digest, Vol 52, Issue 61

[Stephen J. Turnbull]

Miles Bader writes:

 > "Eric S. Raymond" <esr@thyrsus.com> writes:
 > > I have been unable to work on vc.el for about *two weeks* now because
 > > the recommended "make maintainer-clean; configure; make bootstrap"
 > > consistently fails with this:
 > 
 > It never occurred to you to _say something_ during those "two weeks"?

This is starting to look like a duck hunt, what with Glenn just posted
that people who do say something are hurting his feelings.

Isn't it time to stop blaming the beta testers and subsystem
developers, who are *victims* of build breakage, whether it lies with
CVS or a recent change to a Makefile?  It's not so hard to add

.PHONY force-cvs-sanity-so-yall-will-kwitcherbitchin-for-heavens-sake
force-cvs-sanity-so-yall-will-kwitcherbitchin-for-heavens-sake:
        if test -e CVS -a ! -e .cvs_geeks_don_need_yer_steenkin_help; \
                then echo "I want to update CVS, type N to omit once"; \
                echo "type X to omit and inhibit permanently"; \
                echo "type anything else to 'cvs update -dP'"; \
                read -n 1 -t 5 NOCVSUPDATEDP; \
                case $NOCVSUPDATEDP in \
                        [nN] ) echo "Not updating CVS, continuing";; \
                        [xX] ) touch .cvs_geeks_don_need_yer_steenkin_help; \
                               echo "Consider 'update -dP' in ~/.cvsrc"; \
                               sleep 3;; \
                        *    ) echo "Logging to cvs-update.log"; \
                               cvs update -dP >cvs-update.log 2>&1;; \
                esac; \
                unset NOCVSUPDATEDP
        fi; fie; fo; fum

to the Makefile, is it?  And add it as a prerequisite for the
"bootstrap" target?  (I hereby dedicate the above stanza to the public
domain.  Don't cut and paste it, untabify probably got to it.<wink>)

A more radical suggestion: package system.  This is what a package
system is for, preventing propagation of local breakage into global
lossage.  D'oh.

I admit, I'm quite shocked that Alan and Eric didn't know about the
"update -d" flag, and rather surprised that this issue has not come up
in the same way for XEmacs, since our package tree is always in this
kind of flux.  The only thing is that we have a canonical reference,
http://www.xemacs.org/Develop/cvsaccess.html, for use of CVS, which
recommends putting "update -dP" in .cvsrc.[1]  Most places in XEmacs
docs that mention use of CVS point to that, so (I guess) most XEmacs
folks who use CVS have long since seen it and done it.

Footnotes: 
[1]  It may be that it happened in the great package reorganization,
and long since became part of the XEmacs culture.  But I don't recall
newbies to XEmacs development ever having much trouble with it, either.

Re: Emacs-devel Digest, Vol 52, Issue 61

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> A more radical suggestion: package system.  This is what a package
> system is for, preventing propagation of local breakage into global
> lossage.  D'oh.
>
> I admit, I'm quite shocked that Alan and Eric didn't know about the
> "update -d" flag, and rather surprised that this issue has not come up
> in the same way for XEmacs, since our package tree is always in this
> kind of flux.

I actually would not have known/remembered either, but I used to do the
updates pretty much exclusively through PCL-CVS, so I don't need to
know.  Nowadays I usually employ git.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eli Zaretskii]

> Date: Sat, 7 Jun 2008 09:20:37 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> 
> Whoever said expecting builds in CVS to work consistently was
> "hopelessly unrealistic" is simply revealing that the Emacs system
> is broken as designed.

This is free software: you are welcome to fix whatever you think is
broken.

> Maybe this is a *reason* we have so few developers?

Ha!

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Date: Sat, 7 Jun 2008 09:20:37 -0400
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > 
> > Whoever said expecting builds in CVS to work consistently was
> > "hopelessly unrealistic" is simply revealing that the Emacs system
> > is broken as designed.
> 
> This is free software: you are welcome to fix whatever you think is
> broken.

Yeah, like I wouldn't get flamed to fare-thee-well if I shot autotools
through the head and replaced it with something like scons -- which is
only part of what needs to happen.  What we have here is a mess compounded
of the limitations of CVS, Makefiles, and configure, with a semi-infinite
number of layers of historical cruft layered over all three.

The real problem here isn't technical, it's cultural.  This crew is way
too used to rusty, broken, archaic tools like CVS and the high hassle
costs that go with them.  Until that changes, fixing the mess will
be theoretically conceivable but politically impossible.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eli Zaretskii]

> Date: Sat, 7 Jun 2008 15:55:44 -0400
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> The real problem here isn't technical, it's cultural.  This crew is way
> too used to rusty, broken, archaic tools like CVS and the high hassle
> costs that go with them.  Until that changes, fixing the mess will
> be theoretically conceivable but politically impossible.

Sorry, but that's ridiculous.  Next you will tell us that invoking
"configure" and "make" from the shell prompt is ``rusty and broken'',
and is the reason for the fact that you expect the build to fail,
because it's all too easy to try to run "make" before "configure" or
misspell "make" as "Make".

Using CVS and not knowing about -d is like using GCC without knowing
what the -c switch does.

Re: Emacs-devel Digest, Vol 52, Issue 61

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> Sorry, but that's ridiculous.  Next you will tell us that invoking
> "configure" and "make" from the shell prompt is ``rusty and broken'',
> and is the reason for the fact that you expect the build to fail,
> because it's all too easy to try to run "make" before "configure" or
> misspell "make" as "Make".

I'm very, very experienced with these tools.  Enough so that the fact
that they have spiky bits that still gash me occasionally is not an
indictment of me, it's an indictment of the tools.  Yes, they were the
best we could do at one time.  That time is long past.

I've recently had the experience of converting a large project from
autotools to scons.  The difference is amazing -- the LOC of the build
spec files dropped by a factor of 17, the interface is simpler, and
entire classes of build problems just disappeared.

My point isn't to advocate scons specifically, it's to illustrate how
much better and simpler modern tools (like scons, or WAF, por even ant)
are.  We're accepting a lot of breakage and hassles by not using them.
Don't pile blaming the victims on top of that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Emacs-devel Digest, Vol 52, Issue 61

[Thomas Lord]

Eric S. Raymond wrote:
> I'm very, very experienced with these tools.  Enough so that the fact
> that they have spiky bits that still gash me occasionally is not an
> indictment of me, it's an indictment of the tools.  Yes, they were the
> best we could do at one time.  That time is long past.
>
> I've recently had the experience of converting a large project from
> autotools to scons.  The difference is amazing -- the LOC of the build
> spec files dropped by a factor of 17, the interface is simpler, and
> entire classes of build problems just disappeared.
>   


As a point of amusement (and boasting, I guess) I'll mention that 
concurrently
with the original work to create autoconf I worked on a system (a cousin of
the one now more evolved at qef.com) where we got 2-3 orders or magnitude
reductions (100x..1000x) over Imake, fully audited builds, highly flexible
configuration support, efficient and parallelizable  builds, and  yadda  
yadda
yadda --- all by building a handful of very tiny C libraries and simple 
utilities
that were far, far easier to bootstrap than a complete Python install.

That was, alas, proprietary code.    (At the time, the number of  paid 
jobs writing
free software was well short of 10.)

However, not only could we have done better back then, we can probably even
today do better than the advantages you describe for scons.

This is not to slag on scons but to suggest that if your efforts at 
cultural reform
make progress, it might be worth not simply leaping on the shiniest tools
du jour but, stepping back, considering what is actually achievable, and 
thinking
a bit about the goals.

> My point isn't to advocate scons specifically, it's to illustrate how
> much better and simpler modern tools (like scons, or WAF, por even ant)
> are.  We're accepting a lot of breakage and hassles by not using them.
> Don't pile blaming the victims on top of that.
>   


One of my interests is in the possibility of "renewing" the original GNU 
project
to build a complete system which is unix on the bottom but a lot more 
"lisp machine"
in user space.   Another of my interests is in exploring the possibility 
that the large
gap between individual upstream projects and ready-for-use binary 
complete GNU/Linux
systems can be reduced: it shouldn't be so labor intensive to create and 
maintain
distributions.

This could be relevant to your attempts to improve the Emacs project's 
practices.
Greater motivation for changes in tools might be found by considering 
how that
can help create complete systems, if many upstream projects were to 
adopt new
tools.   Configuration and construction are closely related to source 
code management,
auditing, aggregation of code, package systems, and more.   Issue 
tracking that
can be integrated across multiple upstream projects and downstream 
distributions
is another area to explore.

Adopting more ambitious goals might actually simplify advocacy for reform,
clarify decisions about tool choices, and have larger "pay offs" than 
trying to
do it one project at a time.

-t

Re: Emacs-devel Digest, Vol 52, Issue 61

[Stephen J. Turnbull]

Thomas Lord writes:

 > This is not to slag on scons but to suggest that if your efforts at
 > cultural reform make progress, it might be worth not simply leaping
 > on the shiniest tools du jour but, stepping back, considering what
 > is actually achievable, and thinking a bit about the goals.

Nope.  That's mission creep.  Not Emacs's job, mon.