Re: GUB help

[Graham Percival]

On Fri, Dec 30, 2011 at 06:05:17AM +0000, Carl Sorensen wrote:
> I am interested in getting a new stable release of LilyPond out, so I want to 
> work on Critical issues.

Great!  We have definitely suffered from having those critical
issues.

> There are 3 critical issues, all of which will require changes to GUB in 
> order to fix them.

Technically, I think the lilypond-book msvrct one could be fixed
by re-refactoring lilypond-book to avoid that module, but that
would be a pretty bad fix.

> I know nothing about GUB, but I can see that the lack of GUB knowledge is 
> preventing a release candidate.

It took me about 100 hours to feel comfortable with GUB, and it's
in better shape now than it was before I began.  Expect at least
10 hours before you feel like you can make any real improvements.

I offer the following mantras:
- at the most fundamental level, a build system is just a
  framework that decides which commands to run.  If you can figure
  out what command GUB is running (and failing), including any
  relevant environment variables, then you can debug that on the
  command-line without touching GUB.
- once you have the failing command-line, hit up google for the
  error messages.  You can generally find a fix for problems on
  an obscure fink or debian packagers mailing list.
- GUB is 18,000+ lines of python, but it's well-written python.
  It's complicated+long because the task at hand is
  complicated+long.
- it has a fabulous set of logfiles.


> I also set up VirtualBox with lilydev 1.1.
> 
> I've been unable to build GUB with either of these setups.

hmm, I'm using the last lilydev before 2.0 (I think it's 1.2) for
releases, so it definitely works there, at least on my hardware.
I don't think the difference between lilydev 1.1 and 1.2 will be
relevant, though; particularly if you run the ubuntu updates.

I've never tried to build it inside virtualbox, though -- it takes
about 12 hours to get stuff set up on my dual-core while using 8
threads.

> <<<<<<<< Tail of target/darwin-ppc/log/cross/gcc.log

That error message doesn't show me enough to guess, so the next
step is to look in that file.

> powerpc-apple-darwin7-ar: fatal error in 
> /home/carl/gub/target/darwin-ppc/root/usr/cross/bin/powerpc-apple-darwin7-ranlib
>
> Any idea as to what my next step is?

hmm.  If you can reproduce exactly the same error message on a
standalone command-line, maybe you can add a --verbose flag?  I'm
shooting from the hip here; I have no clue if that command has any
--verbose flag or not.

Cheers,
- Graham