[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lybook-db etc etc.
From: |
David Kastrup |
Subject: |
Re: lybook-db etc etc. |
Date: |
Sat, 29 Oct 2011 12:27:05 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) |
Han-Wen Nienhuys <address@hidden> writes:
> On Wed, Oct 26, 2011 at 1:13 PM, David Kastrup <address@hidden> wrote:
>> Well, I am currently in the process of running make info (similar to
>> make doc), and this is totally silly.
>>
>> In my opinion, the whole lybook-db stuff needs to go. Instead, Lilypond
>> is run _once_ for all snippets of a lybook source, generating _one_
>> PostScript file. Then GhostScript is run _once_ to generate a bunch of
>> eps files, or a multi-page PDF file with all graphics in them which get
>> referenced as needed.
>>
>> Bleedover of variables/fonts/whatever is not all that crucial since we
>> are talking about a single document source rather than an immaculate
>> database.
>
> on the contrary: the regtest is a tely document, so bleed will cause
> spurious diffs in the regtest, at least in the pixel comparison.
Bleed would be a bug in the snippets. Global settings would likely need
to be forked out into an initialization file for the whole document.
Anyway, I am more concerned about "make doc" rather than "make test".
To put a perspective to it, I'd figure I could justify working on this
if we managed a pledge of €500 for every factor of 2 I can shave off
"make doc" (starting after "make all" from a fresh checkout), getting
free hand for the interaction between lilypond-book, Lilypond, and
Ghostscript _using_ GNU/Linux (I don't have the means to port, say,
socket communication to Windows, though at first I would stick with
batch processing that should "just work"TM). That would be for a
uniprocessing setup. A separate agreement may be possible for
multiprocessing, but then the results would not be deterministic for
bleedover problems since the set of snippets processed by a single
Lilypond/Ghostscript pipeline would vary from run to run.
--
David Kastrup