On Sun, Jun 26, 2011 at 10:46:15AM +0100, Phil Holmes wrote:
----- Original Message ----- From: "Graham Percival"
<address@hidden>
>I have reverted that commit; the build should behave as usual now.
>I'll take another look at this tomorrow, and we'll go through
>another "patch countdown" for whatever new patch we have.
I reckon this problem would go away if we adopted the "hide output
if QUIET_BUILD is defined" - but I would like to discuss this, as
stated earlier. I'll hold off any further work pending this.
I'd like to treat
lilypond-book --redirect-lilypond-output
as a separate feature request from how (if at all) we use it in
the lilypond build system. I mean, some people use lilypond
inside their own build systems (see today's message on -user about
makefiles), and it would be useful to do more debugging+testing of
--redirect-lilypond-output before re-proposing using it in our
build system.
For example, here's an excerpt of the pre-reverted lilylib.py:
if redirect_output:
stdout_filename = ''.join([log_file, '.log'])
stderr_filename = ''.join([log_file, '.err.log'])
stdout_setting = open(stdout_filename, 'w')
stderr_setting = open(stderr_filename, 'w')
proc = subprocess.Popen (cmd,
shell=True,
universal_newlines=True,
stdout=stdout_setting,
stderr=stdout_setting)
... yeah. No wonder Reinhold saw a 0-byte .err.log file!
You missed it, I missed it, and the entire development community
missed it in the 48-hour patch countdown process. Stuff happens;
there's no value in making a big deal out of it. We just think
about how it happened, and consider adjusting our safeguards.
(in this case, I think it falls within the bounds of "occasional
error" and there's no need to adjust our patch policies)
While looking at this, I was a bit confused about stdout_setting:
139 stdout_setting = None
141 if not show_progress:
142 stdout_setting = subprocess.PIPE
144 if redirect_output:
147 stdout_setting = open(stdout_filename, 'w')
... what's the final value of stdout_setting for any given set of
function arguments? ok, when I've isolated those lines, it's not
too hard to track -- but I'm wondering if a more "functional
programming" approach might be easier to read. Namely, "binding
variables", meaning "you can only assign a value to each variable
once". I think a nested if:else: construct might make it easier
to track what the final value of stdout_setting is going to be.
Could I interest you (or anybody else) in re-submitting a patch
for the
lilypond-book --redirect-lilypond-output
feature? Given the past few days, I'm optimistic that we'll see
more interest in reviewing that patch. Then once we finally *do*
settle on a general policy for build system output, we've got all
(or at least some more?) of the "building blocks" that would be
needed to implement that policy.