Graham Percival <address@hidden> writes:
On Sat, Jun 30, 2012 at 04:39:08PM +0100, Graham Percival wrote:
I suggest reverting recent build commits until git master can
compile ok,
NB: I'm making this suggestion as a normal developer, not as
project manager. If anybody really likes build scripts, sees the
problem, and can fix it quickly (recalling one anonymous survey
commenting that "in the old days everybody could fix everything"
(or something like that)), then by all means go ahead without
reverting anything.
I am currently trying a revert of
commit e6a5019c531bbc6663e0eebc645409148dbd8931
Author: John Mandereau - LilyPond development <address@hidden>
Date: Thu Jun 28 18:32:18 2012 +0200
Clean fonts and docs makefiles, trying to fix 'make -j' race conditions
On my machine (GNU/Linux Fedora 17 x86_64 on an Intel Core 2 Duo),
"make -j3 all" repeatedly calls fontforge before needed .pfb files are
generated and makeinfo/extract_texi_filenames/texi2omf before .texi
file has been generated/copied. Fix this by using order prerequisites
and adding targets to WWW-1 (first stage of doc build); order (rather
than ordinary) prerequisites avoid having always outdated targets,
which would trigger compilation at install.
Remove a rule for Info manual that is no longer needed and which might
short-circuit .dep file generation.
mf/GNUmakefile: also factorize prerequisites in fonts using a macro.
which looks totally complex and invasive regarding the build system. If
this goes through compilation, I'll push the revert to staging. It will
be Patchy-staging's job then to make sure that the revert still passes a
multijob make as well.
"Reverse race conditions" reliably occuring only on single CPU builds
are one of the few things that patchy-staging is not good at detecting.
But since one of the ideas of Patchy is to make good use of impressive
CPU power, that's hard to avoid.
--
David Kastrup