* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
@ 2008-12-25 22:27 Markus Triska
2008-12-27 12:19 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Markus Triska @ 2008-12-25 22:27 UTC (permalink / raw)
To: emacs-pretest-bug
A parallel compilation (-j 2) with today's CVS version aborted with:
In toplevel form:
mh-e/mh-folder.el:34:1:Error: Required feature `mh-e' was not provided
Wrote /Users/mt/emacs/lisp/mh-e/mh-e.elc
Compiling /Users/mt/emacs/lisp/mh-e/mh-funcs.el
make[1]: *** [/Users/mt/emacs/lisp/mh-e/mh-folder.elc] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** Waiting for unfinished jobs....
No MH variant found on the system
Wrote /Users/mt/emacs/lisp/mh-e/mh-funcs.elc
make: *** [lisp] Error 2
After another "$ make -j 2", the compilation proceeded without errors.
The full compilation log is available from:
http://www.logic.at/prolog/log20081225.txt
I have seen this problem only once so far in many tries.
In GNU Emacs 23.0.60.1 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9)
of 2008-12-25 on mt-computer.local
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: nil
default-enable-multibyte-characters: t
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2008-12-25 22:27 bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided Markus Triska
@ 2008-12-27 12:19 ` Eli Zaretskii
2008-12-31 2:30 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2008-12-27 12:19 UTC (permalink / raw)
To: Markus Triska, 1705; +Cc: emacs-pretest-bug, bug-gnu-emacs
> From: Markus Triska <markus.triska@gmx.at>
> Date: Thu, 25 Dec 2008 23:27:56 +0100 (CET)
> Cc:
>
>
> A parallel compilation (-j 2) with today's CVS version aborted with:
>
> In toplevel form:
> mh-e/mh-folder.el:34:1:Error: Required feature `mh-e' was not provided
> Wrote /Users/mt/emacs/lisp/mh-e/mh-e.elc
> Compiling /Users/mt/emacs/lisp/mh-e/mh-funcs.el
> make[1]: *** [/Users/mt/emacs/lisp/mh-e/mh-folder.elc] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make[1]: *** Waiting for unfinished jobs....
> No MH variant found on the system
> Wrote /Users/mt/emacs/lisp/mh-e/mh-funcs.elc
> make: *** [lisp] Error 2
This is because we don't tell Make all the truth about the
dependencies between Lisp files, so it by default assumes that
mh-funcs.elc and mh-e.elc are independent, and compiles them in two
different jobs that run in parallel. But the truth is that
mh-funcs.el says this:
(require 'mh-e)
which causes Emacs to look for mh-e.elc when it compiles mh-funcs.el.
So there's a race condition here between the 2 jobs that Make runs in
parallel under "-j 2": one job compiles mh-e.el and writes mh-e.elc,
while the other job, which compiles mh-funcs.el, reads from mh-e.elc.
In this case, the reading job evidently accessed mh-e.elc after it was
already created, but before it was written in its fullness (as you see
above, the "Wrote /Users/mt/emacs/lisp/mh-e/mh-e.elc" message is
printed _after_ the error message). So the "provide" form was not yet
in mh-e.elc when it was read, and Emacs barfed.
In general, we lack such dependencies all over lisp/Makefile.in, so I
submit that "make -j N" works for us by sheer luck: I'm guessing that
this is due to small values of N and the fact that $(ELCFILES) causes
Make to compile files in alphabetic order, combined with very few
dependencies between Lisp files whose names come close to one another
in that order. But given a large enough value of N (and a
correspondingly large number of processors on the system), we should
see such failures all the time.
I added to lisp/Makefile.in a series of dependencies that should fix
the case of MH-E compilation. Please see if this fixes the problem
for you. If you have more than 2 processors, it would make sense to
try "make -j N" with values of N larger than 2, to increase the
probability of such a clash.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2008-12-27 12:19 ` Eli Zaretskii
@ 2008-12-31 2:30 ` Stefan Monnier
2009-01-02 19:34 ` Bill Wohler
2009-01-03 9:22 ` Eli Zaretskii
0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2008-12-31 2:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 1705, bug-gnu-emacs, Markus Triska, emacs-pretest-bug
> I added to lisp/Makefile.in a series of dependencies that should fix
> the case of MH-E compilation. Please see if this fixes the problem
> for you. If you have more than 2 processors, it would make sense to
> try "make -j N" with values of N larger than 2, to increase the
> probability of such a clash.
This won't solve it in general, because there are many circular
dependencies among Elisp files. Another approach is to just close the
race condition: write the byte-compiled file to foo.elc.temp and then
rename it atomically to foo.elc.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2008-12-31 2:30 ` Stefan Monnier
@ 2009-01-02 19:34 ` Bill Wohler
2009-01-03 9:22 ` Eli Zaretskii
1 sibling, 0 replies; 13+ messages in thread
From: Bill Wohler @ 2009-01-02 19:34 UTC (permalink / raw)
To: emacs-pretest-bug; +Cc: bug-gnu-emacs
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I added to lisp/Makefile.in a series of dependencies that should fix
>> the case of MH-E compilation. Please see if this fixes the problem
>> for you. If you have more than 2 processors, it would make sense to
>> try "make -j N" with values of N larger than 2, to increase the
>> probability of such a clash.
>
> This won't solve it in general, because there are many circular
> dependencies among Elisp files. Another approach is to just close the
> race condition: write the byte-compiled file to foo.elc.temp and then
> rename it atomically to foo.elc.
Thanks Eli and Stefan. My laptop isn't a multi-processor box (yet) so
I can't be of more assistance. All I can say is that with the last big
MH-E reorganization going into MH-E 8.0, we eliminated all circular
dependencies within MH-E. I can't speak for the packages we require,
however.
--
Bill Wohler <wohler@newt.com> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2008-12-31 2:30 ` Stefan Monnier
2009-01-02 19:34 ` Bill Wohler
@ 2009-01-03 9:22 ` Eli Zaretskii
2009-01-05 4:12 ` Stefan Monnier
1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2009-01-03 9:22 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1705, bug-gnu-emacs, markus.triska, emacs-pretest-bug
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 1705@emacsbugs.donarmstrong.com, Markus Triska <markus.triska@gmx.at>, emacs-pretest-bug@gnu.org, bug-gnu-emacs@gnu.org
> Date: Tue, 30 Dec 2008 21:30:33 -0500
>
> > I added to lisp/Makefile.in a series of dependencies that should fix
> > the case of MH-E compilation. Please see if this fixes the problem
> > for you. If you have more than 2 processors, it would make sense to
> > try "make -j N" with values of N larger than 2, to increase the
> > probability of such a clash.
>
> This won't solve it in general, because there are many circular
> dependencies among Elisp files. Another approach is to just close the
> race condition: write the byte-compiled file to foo.elc.temp and then
> rename it atomically to foo.elc.
But adding dependencies is TRT on its own right, even if your
alternative is adopted. As long as the byte compiler cannot grok
those dependencies by itself, that is.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2009-01-03 9:22 ` Eli Zaretskii
@ 2009-01-05 4:12 ` Stefan Monnier
2009-01-05 20:00 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2009-01-05 4:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 1705, bug-gnu-emacs, markus.triska, emacs-pretest-bug
>> This won't solve it in general, because there are many circular
>> dependencies among Elisp files. Another approach is to just close the
>> race condition: write the byte-compiled file to foo.elc.temp and then
>> rename it atomically to foo.elc.
> But adding dependencies is TRT on its own right,
Personally, I've hacked my Emacs so that when byte-compiling files,
`require'd files get loaded from the .el in preference to the .elc file
if it's more recent.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2009-01-05 4:12 ` Stefan Monnier
@ 2009-01-05 20:00 ` Eli Zaretskii
2009-01-05 22:21 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2009-01-05 20:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1705, bug-gnu-emacs, markus.triska, emacs-pretest-bug
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 1705@emacsbugs.donarmstrong.com, markus.triska@gmx.at, emacs-pretest-bug@gnu.org, bug-gnu-emacs@gnu.org
> Date: Sun, 04 Jan 2009 23:12:58 -0500
>
> Personally, I've hacked my Emacs so that when byte-compiling files,
> `require'd files get loaded from the .el in preference to the .elc file
> if it's more recent.
I don't think this is TRT in general.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2009-01-05 20:00 ` Eli Zaretskii
@ 2009-01-05 22:21 ` Stefan Monnier
2009-01-06 4:06 ` Eli Zaretskii
2009-01-06 12:31 ` Richard M Stallman
0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2009-01-05 22:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 1705, bug-gnu-emacs, markus.triska, emacs-pretest-bug
>> Personally, I've hacked my Emacs so that when byte-compiling files,
>> `require'd files get loaded from the .el in preference to the .elc file
>> if it's more recent.
> I don't think this is TRT in general.
Neither is the preference of .elc even if it's older.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2009-01-05 22:21 ` Stefan Monnier
@ 2009-01-06 4:06 ` Eli Zaretskii
2009-01-06 15:00 ` Stefan Monnier
2009-01-06 12:31 ` Richard M Stallman
1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2009-01-06 4:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1705, bug-gnu-emacs, markus.triska, emacs-pretest-bug
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 1705@emacsbugs.donarmstrong.com, markus.triska@gmx.at, emacs-pretest-bug@gnu.org, bug-gnu-emacs@gnu.org
> Date: Mon, 05 Jan 2009 17:21:23 -0500
>
> >> Personally, I've hacked my Emacs so that when byte-compiling files,
> >> `require'd files get loaded from the .el in preference to the .elc file
> >> if it's more recent.
>
> > I don't think this is TRT in general.
>
> Neither is the preference of .elc even if it's older.
I wasn't arguing for that, I was arguing for adding dependencies to
lisp/Makefile.in. That is always TRT.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2009-01-06 4:06 ` Eli Zaretskii
@ 2009-01-06 15:00 ` Stefan Monnier
2009-01-06 20:36 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2009-01-06 15:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 1705, bug-gnu-emacs, markus.triska, emacs-pretest-bug
>> >> Personally, I've hacked my Emacs so that when byte-compiling files,
>> >> `require'd files get loaded from the .el in preference to the .elc file
>> >> if it's more recent.
>> > I don't think this is TRT in general.
>> Neither is the preference of .elc even if it's older.
> I wasn't arguing for that,
I know.
> I was arguing for adding dependencies to
> lisp/Makefile.in. That is always TRT.
Except when there are circular dependencies, which (as mentioned) do
exist in fairly large quantities in Emacs.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2009-01-06 15:00 ` Stefan Monnier
@ 2009-01-06 20:36 ` Eli Zaretskii
2009-01-06 22:15 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2009-01-06 20:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1705, bug-gnu-emacs, markus.triska, emacs-pretest-bug
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 1705@emacsbugs.donarmstrong.com, markus.triska@gmx.at, emacs-pretest-bug@gnu.org, bug-gnu-emacs@gnu.org
> Date: Tue, 06 Jan 2009 10:00:59 -0500
>
> > I was arguing for adding dependencies to
> > lisp/Makefile.in. That is always TRT.
>
> Except when there are circular dependencies
Of course, that goes without saying. Make will simply barf on
circular dependencies.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2009-01-06 20:36 ` Eli Zaretskii
@ 2009-01-06 22:15 ` Stefan Monnier
0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2009-01-06 22:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 1705, bug-gnu-emacs, markus.triska, emacs-pretest-bug
>> > I was arguing for adding dependencies to
>> > lisp/Makefile.in. That is always TRT.
>> Except when there are circular dependencies
> Of course, that goes without saying. Make will simply barf on
> circular dependencies.
Not only that, but the build order will not be correct (at least
insofar as the dependencies are really needed). Which is why another
solution is also needed.
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided
2009-01-05 22:21 ` Stefan Monnier
2009-01-06 4:06 ` Eli Zaretskii
@ 2009-01-06 12:31 ` Richard M Stallman
1 sibling, 0 replies; 13+ messages in thread
From: Richard M Stallman @ 2009-01-06 12:31 UTC (permalink / raw)
To: Stefan Monnier, 1705; +Cc: emacs-pretest-bug, markus.triska
Neither is the preference of .elc even if it's older.
In general, it is right to load the .elc even if older,
because that way editing the source code does not
immediately force you to use your new code.
You get to choose (by compiling) when to make it active.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-01-06 22:15 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-12-25 22:27 bug#1705: 23.0.60; parallel build failure: `mh-e' was not provided Markus Triska
2008-12-27 12:19 ` Eli Zaretskii
2008-12-31 2:30 ` Stefan Monnier
2009-01-02 19:34 ` Bill Wohler
2009-01-03 9:22 ` Eli Zaretskii
2009-01-05 4:12 ` Stefan Monnier
2009-01-05 20:00 ` Eli Zaretskii
2009-01-05 22:21 ` Stefan Monnier
2009-01-06 4:06 ` Eli Zaretskii
2009-01-06 15:00 ` Stefan Monnier
2009-01-06 20:36 ` Eli Zaretskii
2009-01-06 22:15 ` Stefan Monnier
2009-01-06 12:31 ` Richard M Stallman
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).