[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Logfiles from build
From: |
Phil Holmes |
Subject: |
Re: Logfiles from build |
Date: |
Fri, 17 Jun 2011 16:35:47 +0100 |
----- 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
- Logfiles from build, Phil Holmes, 2011/06/17
- Re: Logfiles from build, Graham Percival, 2011/06/17
- Re: Logfiles from build, Phil Holmes, 2011/06/17
- Re: Logfiles from build, Graham Percival, 2011/06/17
- Re: Logfiles from build, Graham Percival, 2011/06/17
- Re: Logfiles from build,
Phil Holmes <=
- Re: Logfiles from build, Graham Percival, 2011/06/17
- Re: Logfiles from build, Phil Holmes, 2011/06/17
- Re: Logfiles from build, Graham Percival, 2011/06/17
- Re: Logfiles from build, Julien Rioux, 2011/06/17
- echo but return false in make (was: Logfiles from build), Graham Percival, 2011/06/17
- Re: echo but return false in make (was: Logfiles from build), Graham Percival, 2011/06/17
- Re: echo but return false in make, Julien Rioux, 2011/06/17
- Re: echo but return false in make (was: Logfiles from build), Matthias Kilian, 2011/06/17
- Re: echo but return false in make (was: Logfiles from build), Graham Percival, 2011/06/17
- Re: echo but return false in make, David Kastrup, 2011/06/17