Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1176)

Issue 569400043: Use $(MAKE) instead of 'make' in lilypond-book regtests (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
4 months, 2 weeks ago by hanwenn
Modified:
4 months, 2 weeks ago
Reviewers:
Dan Eble, lemzwerg, dak
CC:
lilypond-devel_gnu.org
Visibility:
Public.

Description

Use $(MAKE) instead of 'make' in lilypond-book regtests This enables parallel builds of lilypond-book tests

Patch Set 1 #

Patch Set 2 : all problems #

Total comments: 1
Unified diffs Side-by-side diffs Delta from patch set Stats (+5 lines, -6 lines) Patch
M Documentation/GNUmakefile View 1 1 chunk +2 lines, -2 lines 0 comments Download
M elisp/GNUmakefile View 1 1 chunk +1 line, -1 line 0 comments Download
M input/regression/lilypond-book/GNUmakefile View 1 chunk +1 line, -1 line 1 comment Download
M vim/GNUmakefile View 1 1 chunk +1 line, -2 lines 0 comments Download

Messages

Total messages: 10
hanwenn
all problems
4 months, 2 weeks ago (2020-02-22 21:43:42 UTC) #1
lemzwerg
LGTM
4 months, 2 weeks ago (2020-02-22 22:00:33 UTC) #2
Dan Eble
How does this interact with CPU_COUNT, which is documented in the Contributor's Guide thus (emphasis ...
4 months, 2 weeks ago (2020-02-22 22:27:05 UTC) #3
hanwenn
On 2020/02/22 22:27:05, Dan Eble wrote: > How does this interact with CPU_COUNT, which is ...
4 months, 2 weeks ago (2020-02-22 23:17:50 UTC) #4
hanwenn
On 2020/02/22 23:17:50, hanwenn wrote: > you were already potentially in a state where you ...
4 months, 2 weeks ago (2020-02-22 23:18:43 UTC) #5
hanwenn
https://codereview.appspot.com/569400043/diff/549600043/input/regression/lilypond-book/GNUmakefile File input/regression/lilypond-book/GNUmakefile (right): https://codereview.appspot.com/569400043/diff/549600043/input/regression/lilypond-book/GNUmakefile#newcode42 input/regression/lilypond-book/GNUmakefile:42: .NOTPARALLEL: here.
4 months, 2 weeks ago (2020-02-22 23:18:49 UTC) #6
dak
On 2020/02/22 23:18:43, hanwenn wrote: > On 2020/02/22 23:17:50, hanwenn wrote: > > you were ...
4 months, 2 weeks ago (2020-02-22 23:29:15 UTC) #7
hanwenn
On Sun, Feb 23, 2020 at 12:29 AM <dak@gnu.org> wrote: > > On 2020/02/22 23:18:43, ...
4 months, 2 weeks ago (2020-02-22 23:56:23 UTC) #8
dak
On 2020/02/22 23:56:23, hanwenn wrote: > On Sun, Feb 23, 2020 at 12:29 AM <mailto:dak@gnu.org> ...
4 months, 2 weeks ago (2020-02-23 00:10:31 UTC) #9
hanwenn
4 months, 2 weeks ago (2020-02-23 19:29:00 UTC) #10
On 2020/02/23 00:10:31, dak wrote:
> On 2020/02/22 23:56:23, hanwenn wrote:
> > On Sun, Feb 23, 2020 at 12:29 AM <mailto:dak@gnu.org> wrote:
> > >
> > > On 2020/02/22 23:18:43, hanwenn wrote:
> > > > On 2020/02/22 23:17:50, hanwenn wrote:
> > > > > you were already potentially in a state where you have 3 jobs each
> > > spawning 3
> > > > > lp-book invocations,
> > > >
> > > > whoops, I mean: 3 lp-book invocations spawning 3 lilypond subprocesses
> > > each, for
> > > > 9 in total.
> > >
> > > Considering that I build with CPU_COUNT=9 make -j9 I am pretty sure that
> > > I'd have noticed if that were happening so far.  I may have a nice
> > > number of cores (4) and memory considered plentiful (16GB) for a laptop,
> > > but 81 parallel instances of LilyPond would certainly bring this system
> > > to its knees.
> > 
> > In practice, this doesn't happen, because our build system doesn't
> > parallelize all that well, and we don't have much large lp-book
> > documents anyway
> 
> But this patch attempts to make it happen, right?

abandoning this for 
https://codereview.appspot.com/555360043/
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b