Re: Logfiles from build

[Phil Holmes]

----- Original Message ----- 
From: "Graham Percival" <address@hidden>
To: "Phil Holmes" <address@hidden>
Cc: <address@hidden>
Sent: Friday, June 17, 2011 4:19 PM
Subject: Re: Logfiles from build


> On Fri, Jun 17, 2011 at 11:53:15AM +0100, Phil Holmes wrote:
> > ----- Original Message ----- From: "Graham Percival"
> > <address@hidden>
> >
> > >On Fri, Jun 17, 2011 at 09:34:38AM +0100, Phil Holmes wrote:
> > >Before any work is done on the central log/ or
> > >build-log/ directory, I would really like to have the capability
> > >to automatically display the tail of a log-file which did not
> > >complete 'make' successfully.
>
> > With the exception of lilypond itself, where the warnings seem
> > inextricably linked with the progress output, then nothing I am
> > doing is aimed at redirecting error output - quite the reverse - I
> > now see errors in the build which no-one else sees.
>
> I hate to be a downer, but this not true.

If I'm being really picky, I'm probably still right, since I now see them as 
part of a normal build when no-one else can (since there's normally so much 
other cruft), but I understand what you say.

> My finger slipped and I deleted your email about fontforge, but
> those have been around for ages:
> http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00490.html
> http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00987.html

OK.  Just checking they're known.

> We even know how to fix them; in 2008, the answer was "compile
> with --enable-double".  In fontforge 20110222 we can check the
> --version output to make sure that this option was enabled.  But
> nobody has stepped forward to offer a patch for configure.in, so
> this won't be done, and in another 8-14 months, somebody will
> probably ask the same question.
>
> Finding warnings is good, but unless anybody fixes them, you might
> as well spend your time watching youtube videos of kittens.  :(

I've done that, as well.  I like the one "driving" the roomba...

> I can already tell that nothing's going to happen to your email
> here:
> http://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00384.html

Not suggesting it has to happen, simply checking whether these are 
known/problematic.

> In keeping with the GOP mentor discussion, (proposal summary)
> http://lilypond.org/~graham/gop/gop_2.html
> I feel compelled to warn you that you do not have "a realistic
> expectation of how things will work".  I hate to say it, but every
> instinct I have from watching lilypond development is screaming at
> me that this will end in tears, dissapointment, and/or bitter
> recriminations.  I've seen it happen again and again.  :(

I hope not - see below.

> > I'd suggest we work down this route, and then consider whether a
> > grep of the logfile contents for "warning" and "error" reveals
> > anything that needs sorting out.
>
> Another avenue of miscommunication is that, in the context of
> make, "error" means "the command exited with a non-zero status
> message", while "warning" means "anything else".  (or something
> like that)

> So when Reinhold and I say "we must not hide any errors in make",
> we're not talking about stuff in fontforge, or lilypond saying
> "programming error: foo is not bar'd", or anything like that --
> we're talking about something which causes *make* to stop the
> build process.  It doesn't matter if a program outputs "this is a
> serious error, I'm not kidding, pay attention"... in the context
> of a *make* discussion, that's (implicitly) not considered an
> *error*.

In that case, I can't see that anything I can do can prevent these being 
visible.  The only thing I can do is make it a little more difficult to find 
why the problem occurred, by directing output to logfiles rather than the 
terminal screen.  But in the long run, doing it this way must be better.  At 
present, if a build fails owing to a problem way back in the process, you'd 
need to re-run the build with redirected output and then work your way 
through it to find the problem.  With most output already in logfiles, it'll 
either be visible in the terminal, or grepping the logfiles will show it, or 
looking at the logfiles in chronological order will.

> yikes, this is a mess.  You need a mentor (or organizer, or
> manager, or devel translator, or whatever we want to call it).
> There's just too much "mistranslation" going on.
>
> I guess I'm it, if you're willing.

I think I'd kind-of assumed that already.

> If you *are* willing, then my first "instruction/guidance" is to
> pick ONE aspect of the build process and focus on that.  Do not
> spend time on other parts of the build system.  And if there is a
> problem with that one aspect, continue working on that until it is
> done.

The one aspect I'm concentrating on (well, slightly 2 really) is 
understanding the build process a little better, and reducing the clutter 
sent to the terminal.  As it now stands, a make doc produces 104,000 lines 
of output, down from 540,000.  I've diverted onto make temporarily, and if 
you now run (on my system) make -s QUIET_BUILD=1 you only get 1400 lines of 
output.  The only reason I ask about whether the other errors are known is 
in case they're important and not known.

--
Phil Holmes