Helge Kruse-2 wrote:
>
> Am 18.02.2012 00:30, schrieb Michael Hendry:
>>
>> Obviously, I can comment out the sections I don't want during data entry
>> work, and remove the comments once the work is complete, but it would be
>> handy to be able to use a C-like construct like this:
>>
>>
>> #DEFINE NotYet
>> ...
>> #IFNDEF NotYet
>> \book {
>> \bookOutputName "Chez Fernand (alto)"
>> \new Score
>> <<
>> \transpose f' d {\TheChords}
>> \new Staff
>> \repeat unfold 13 {
>> s1 \noBreak s1 \noBreak s1 \noBreak s1 \break }
>> \transpose f' d {\TheHead}
>>>>
>> \header {piece = "Alto Sax"}
>> }
>> #ENDIF
> What about block comment? I can't see why editing the file to change
> #DEFINE is preferred to editing the file to change the block comment.
>
> %{
> \book {
> \bookOutputName "Chez Fernand (alto)"
> \new Score
> <<
> \transpose f' d {\TheChords}
> \new Staff
> \repeat unfold 13 {
> s1 \noBreak s1 \noBreak s1 \noBreak s1 \break }
> \transpose f' d {\TheHead}
> >>
> \header {piece = "Alto Sax"}
> }
> %}
>
> Helge
>
> _______________________________________________
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
Thanks for your comment, Helge. Of course, I know about block comments, and
if there were only one section I wanted to suppress during the development
of piece that would be fine. But I have several sections I'd like to switch
off during data entry, and I'd like to be able to switch them all on again
with a single edit without having to remember where they are - in much the
same way as a C programmer will scatter debugging code through a project,
and switch it off for the final compilation.
So it would be:
#define debugging
... several pages of code ...
#ifdef debugging
... print something on the screen, and await a user response ...
#endif
... several more pages of code ...
#ifdef debugging
... do something else that's useful in the debugging process ...
#endif
... and so on ...
Of course, for lilypond I'd be using the process in reverse - leaving out
known-to-function bits of code while concentrating on other bits - and it's
good practice not to keep commenting out and commenting in - there's always
the risk of accidentally removing a crucial character, or getting the
bracketing wrong.
I know I'll be accused of laziness, but I'd like to be able to concentrate
on the music, and be able to develop reliable blocks of supporting code I
can incorporate in any piece - in this instance I'd have to use a variable
in place of "Chez Fernand" to make the code more portable, it could then be
brought in using "\include" wherever I wanted it.
I envisage a series of #define statements at the head of the main .ly file
such as:
#define concert_part
#define guitar_part
#undef alto_part
#define clarinet_part
which would alter the output from the included "parts.ly" file.
I'd previously had a look at tags in Lilypond, but couldn't see how to apply
them cleanly in this context.
--
View this message in context:
http://old.nabble.com/Is-there-an-equivalent-of--define-...--ifndef-...--endif-in-lilypond--tp33346188p33351266.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
