Re: How to include a file just once?

[Michael J. O'Donnell]

I already separate notes from layout, since I want to layout the same
notes in chorus only, chorus with piano reduction, maybe others. But, I
also want to compile parts one at a time, as well as together.

Currently, I have

22-Behold_the_Lamb_of_God-chorus.ly
22-Behold_the_Lamb_of_God-music-words.ly
37-The_Lord_Gave_the_Word-chorus.ly
37-The_Lord_Gave_the_Word-music-words.ly
47-Behold_I_Tell_You_a_Mystery-chorus.ly
47-Behold_I_Tell_You_a_Mystery-music-words.ly
Too_Hot_to_Handel-chorus.ly
Too_Hot_to_Handel-style.ly

where each of the *-chorus.ly files \includes the *-style.ly file. All
notes and lyrics are in the *-music-words.ly files, and all layout in
the *-chorus.ly files, with globally used definitions and parameter
settings in Too_Hot_to_Handel-style.ly. Too_Hot_to_Handel-chorus.ly
includes each of the other *-chorus.ly files to put together the whole
thing (there are 10 more numbers to go, and the initial numbers come
from Handel's whole work, only part of which is in this arrangement).

Each indivdual number is a \bookpart.

I will add piano reductions, and any other parts I decide to set, to the
same *-music-words.ly files. Then, I will create things like
22-Behold_the_Lamb_of_God-chorus-piano.ly and
Too_Hot_to_Handel-chorus-piano.ly with appropriate layout.

There are plenty of good reasons to be able to produce individual
numbers without even compiling the whole thing, and plenty of good
reasons to avoid editing the files as much as possible when producing
different variations (i.e., just selecting the right top-level file, not
editing other files).

I could have a skeleton output producer for each number, similar to the
skeleton output producer for the whole collection. E.g.
22-Behold_the_Lamb_of_God-chorus-outputSkeleton.ly might contain only

\include "Too_Hot_to_Handel-style.ly"
\include "22-Behold_the_Lamb_of_God-chorus.ly"

but that is unnecessarily indirect.

Many other languages, including most programming languages, and also the
LaTeX typesetting system, have recognized the value of declaring in file
A that it requires file B, and automatically including B if it has not
already been included by another such requirement. There's a whole lot
of experience showing that this is the better way to go than multiplying
the skeleton files. I am confident that I could implement it as a Scheme
function in LilyPond, but I hope that someone has already done it.

Thanks,

Mike O'Donnell

James Bailey wrote:
>
> On 21.01.2010, at 18:47, Michael J. O'Donnell wrote:
>
>> Is there a standard way to make sure that a file full of LilyPond style
>> definitions is included just once, no matter how many times it is
>> mentioned?
>>
>> I searched the Web site, mail archives, and /usr/shar/lilypond for
>> "include once" and "include guard", to no avail. With the C
>> preprocessor, there is a standard trick for setting and testing a
>> variable to disable all but the first attempt to include a header file.
>> Some languages have an "include-once" command.
>>
>> I am putting together a large choral score from bookparts for each
>> number in the work. I like to be able to produce either a single number,
>> or the whole score. The natural approach is to include style definitions
>> in each of the files that I might set, including the file to format the
>> whole score and the files to format individual numbers. Files to format
>> individual numbers also include the style definitions.
>>
>> I find that repeated inclusion of the same definitions leads quickly to
>> a segmentation fault.
>>
>> I can either add one more level of indirection, with one more file per
>> number. Or, I can do some Scheme hacking, with a global variable to set
>> showing inclusion (tricky, because the variable needs to be testable
>> reliably even when it has never been set explicitly).
>>
>> But, I'd prefer to use a well-known standard method, if it exists.
>>
>> Thanks,
>>
>> Mike O'Donnell
>>
>
> One solution might be to have either notes or layout definitions in a
> file, but not both. It quickly leads to large amounts of files, but
> you can have separate book files which create the actual parts, and
> not have multiple includes.
>