CG guide to building GUB

Some notes on how to set up a GUB build environment.

[PhilEHolmes, 2012-05-06 11:11:21]

Please review

[Graham Percival, 2012-05-06 11:27:47]

great start; a few notes for you or James to investigate.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
File Documentation/contributor/build-notes.itexi (right):

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
Documentation/contributor/build-notes.itexi:1517: you will have to start again. 
64 GBytes should be sufficient.
I'm quite happy with recommending a large disk size for this, but my own gub/
dir (including target/) is 14 megs, and that directory is untouched since
building 2.15.38.

If yours is larger, do you have multiple target/ directories (i.e. a backup?),
or is it because the filesystem itself only stores larger files, or lots of old
regtest tarballs, or...?

again, I'm totally on board with recommending a large disk.  I just think it
would be good to investigate this discrepancy.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
Documentation/contributor/build-notes.itexi:1520: impossible to restart.  If at
all possible, leave the build to
I'd say "extremely difficult" here, instead of "impossible".  You can find the
package that failed to build, then force a complete rebuild with some archaic
set of commands that are probably listed in the README, then continue as
expected... but it's easier just to nuke the whole target/ dir and start from
scratch.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
Documentation/contributor/build-notes.itexi:1526: git clone
git://github.com/janneke/gub.git
please point to my gub dir now, since it has extra bugfixes compared to Jan's
version.
https://github.com/gperciva/gub

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
Documentation/contributor/build-notes.itexi:1535:
@uref{http://www.cpan.org/src/5.0/perl-5.10.0.tar.gz}, saving the
could you (or James) double-check this?

According to my notes from 2012 Feb 17, manual attention is only needed for
  bin/gub tools::netpbm
  bin/gub tools::rsync
http://code.google.com/p/lilypond/issues/detail?id=2184

[PhilEHolmes, 2012-05-06 13:06:09]

On 2012/05/06 11:27:47, Graham Percival wrote:
> great start; a few notes for you or James to investigate.
> 
>
http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
> File Documentation/contributor/build-notes.itexi (right):
> 
>
http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
> Documentation/contributor/build-notes.itexi:1517: you will have to start
again. 
> 64 GBytes should be sufficient.
> I'm quite happy with recommending a large disk size for this, but my own gub/
> dir (including target/) is 14 megs, and that directory is untouched since
> building 2.15.38.
> 
> If yours is larger, do you have multiple target/ directories (i.e. a backup?),
> or is it because the filesystem itself only stores larger files, or lots of
old
> regtest tarballs, or...?
> 
> again, I'm totally on board with recommending a large disk.  I just think it
> would be good to investigate this discrepancy.

The filesystem I created was 64 Gigs, and it shows 36.8 free - so 30 gigs is the
bare minimum.  My GUB directory is about 12 Gigs, and my total file size is
around 17 Gigs, so there's other stuff like file system overhead, swap, etc.,
using up some other space.
 
>
http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
> Documentation/contributor/build-notes.itexi:1520: impossible to restart.  If
at
> all possible, leave the build to
> I'd say "extremely difficult" here, instead of "impossible".  You can find the
> package that failed to build, then force a complete rebuild with some archaic
> set of commands that are probably listed in the README, then continue as
> expected... but it's easier just to nuke the whole target/ dir and start from
> scratch.

I've changed it to say "almost impossible".
 
>
http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
> Documentation/contributor/build-notes.itexi:1526: git clone
> git://github.com/janneke/gub.git
> please point to my gub dir now, since it has extra bugfixes compared to Jan's
> version.
> https://github.com/gperciva/gub

I assume git://github.com/gperciva/gub is the correct syntax for the git clone?
 
>
http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-...
> Documentation/contributor/build-notes.itexi:1535:
> @uref{http://www.cpan.org/src/5.0/perl-5.10.0.tar.gz}, saving the
> could you (or James) double-check this?
> 
> According to my notes from 2012 Feb 17, manual attention is only needed for
>   bin/gub tools::netpbm
>   bin/gub tools::rsync
> http://code.google.com/p/lilypond/issues/detail?id=2184

It did fail for me consistently, a number of times.  However, I'm only really
giving it as an example of what to do if any package fails to download.

[Graham Percival, 2012-05-06 13:21:23]

On 2012/05/06 13:06:09, PhilEHolmes wrote:
> The filesystem I created was 64 Gigs, and it shows 36.8 free - so 30 gigs is
the
> bare minimum.  My GUB directory is about 12 Gigs, and my total file size is
> around 17 Gigs,

ah, that makes sense.  I was only looking at the directory, but of course the
most important thing somebody needs to know is how large to make the partition.

> > https://github.com/gperciva/gub
> 
> I assume git://github.com/gperciva/gub is the correct syntax for the git
clone?

Yes, that's what I see on the github page.  I haven't tested it myself, but that
looks like the right form... no wait.  I see this:
git://github.com/gperciva/gub.git
(with an extra .git at the end)


> > According to my notes from 2012 Feb 17, manual attention is only needed for
> >   bin/gub tools::netpbm
> >   bin/gub tools::rsync
> > http://code.google.com/p/lilypond/issues/detail?id=2184
> 
> It did fail for me consistently, a number of times.

Before or after Feb 17?

> However, I'm only really
> giving it as an example of what to do if any package fails to download.

My point is that you shouldn't need to poke around inside the downloads/
directory manually, and AFAIK the above commands are the only ones that you need
to do.  I'm sure that I completely wiped my target/ and download/ directories
and rebuilt from scratch, so in Feb it was possible to avoid poking around
manually.  Something may have changed before or after then, of course.

Hopefully James will run these instructions later this afternoon and then he can
tell us if there's any problems or not.

- Graham