Re: lybook-db etc etc.

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> Am 2011-10-26 17:13, schrieb David Kastrup:
>> 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,
>
> Lilypond is currently run _once_ for all snippets. In particular, it
> is called by lilypond-book with snippet-names.* as input file, listing
> all files to process.
>
>> 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.
>
> This is a fundamental deviation from how lilypond works currently, and
> it's probably hard to get it right.

It was not easy to get right in preview-latex.  I did not say it was.
But the current build system is _impossible_ to get right.

> Currently, lilypond processes one file after the other in a loop,
> properly cleaning up after each file, and the corresponding backend
> does its job one file at a time.
>
> You are proposing that all backends should be split into two stages,
> one to create the ps files (for the (|e)ps backend at least) and one
> to convert them to pdf/pngs. This does not affect only lilypond-book,
> but lilypond being run on multiple files in general.
>
> What if one file fails to compile? Imagine you are running multiple
> files at once, i.e.
>   lilypond file1.ly file2.ly file3.ly file4.ly
> and file4.ly contains a syntax error. So far, file1, file2 and file3
> will have been properly processed and finished (i.e. their
> *.pdf/svg/eps/ps/scm output files have been created), only file4
> failed.
>
> With your proposal, all already compiles files will have only half of
> the work done, but no PDF created. So basically you will have NO pdf
> output at all for any of the files.

Why?  You create an empty snippet and continue.  If you manage to crash
Lilypond uncontrolledly (seg fault etc), you get no output.  So what?
If you crash it in mid-document for non-snippetized documents, that's
just the same.

>> Bleedover of variables/fonts/whatever is not all that crucial since
>> we are talking about a single document source rather than an
>> immaculate database.
>
> How does your proposal work with files that e.g. change the scheme
> options, like resolution?

Changing resolution between pages is feasible in PostScript.  But where
is the point to change resolution _in_ _one_ _lilypond-book_ _document_?

> Actually, it will not simplify the build system that much. All the
> work you are describing is done by lilypond-book, and the build system
> only calls lilypond-book on the list of snippets (with some copying of
> output files, of course, which complicates things; that will be
> simplified).

Oh, it will.  The whole nonsense of copying snippet sources should go as
well.  lilypond-book should hand lilypond a list of source files (via
pipe, socket, or tempfile), offsets and lengths, and then lilypond uses
the source, Luke.  Reporting its errors where they actually occur in the
lybook files.

No copying of input files.  No copying of output files.

-- 
David Kastrup