[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to run GUB

From: Graham Percival
Subject: Re: How to run GUB
Date: Sun, 18 Mar 2012 14:33:27 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Mar 18, 2012 at 12:15:20PM -0000, Phil Holmes wrote:
> # A general rule: do not interrupt a build.  It seems to use file locks
> #  as a way of controlling multi-cpu builds, and it can get confused
> #  if interrupted.  I've had to start from scratch in this case. :-(

It's possible to recover from this, but it's icky.  Agreed on not
interrupting it.

> # Throughout the instructions I use -jx.  I'm not certain this is
> needed, but
> #  if it does make it run faster, good.  x=your CPUs + 1

Not needed; GUB uses 2* your CPUs for any package where it's safe
to do so.

> # At this point it fails since the perl archive never properly
> downloads for some reason.
> # Go to and save it to
> # /home/gub/gub/downloads/perl/

Hmm, I didn't see that the last time I tried a build from scratch,
about a month ago?

> make -jx bootstrap


> make -jx # This takes a loooong time...

no.  I don't even know what make does -- maybe it build absolutely
everything?  It's certainly not anything that I run.

> make -jx lilypond

I recommend getting the regtests first?

> # The build may fail because it wants a tarball of the regtests.
> # Create this as follows: (there may be an easier way...)

Much easier way: download the test output from, i.e.

> touch regtests/ignore


> # Restart the build
> make -jx lilypond

Yes, although this builds master.  I recommend
  make LILYPOND_BRANCH=release/unstable lilypond
instead, since master may have random breakage.  When you're
dealing with a large and unknown environment like GUB, it's good
to reduce potential confusion.

- Graham

reply via email to

[Prev in Thread] Current Thread [Next in Thread]