Am 26.06.2018 um 01:25 schrieb Aaron Hill:
On 2018-06-25 15:51, David Kastrup wrote:
Nah <sche...@runbox.com> writes:
I have a project with 100+ scores, each in their own file. I tried to
create a Scheme function to \include each of them. After searching the
archive, I got the general idea of why my solution isn't
working. However, I didn't find something like a snippet that I could
coax into what I want. I have programming experience in C, Python,
etc., but I'm still pretty clueless with Scheme.
What I want is a function that does something like:
foreach fname #{ \include #fname #}
In Python, I would just read all the filenames in the directory, sort
them, then run the foreach. Can I do something like that in Scheme?
And how do I put the result in a form that will work with \include?
Be aware that this is quite a bad idea if the file itself is in the
directory we are talking about here...
A little unterminated recursion never hurt anyon...
StackOverflowException. :)
Out of curiosity, is there a way to do an inclusion guard like the
C-style `#ifndef/#define/#endif` or `#pragma once` within LilyPond?
Not directly.
Similarly, is there a way to know that a file was included vs. being
the top-level file?
Also, not directly. But you can make it happen.
Basically you have to define some variable in the top-level file, say
#(define is-main-file #t). Then you can check in the included file for
#(if (defined? is-main-file)
Scenario: I am trying to typeset a work consisting of multiple
pieces. I have a single top-level `.ly` file that is responsible for
including the individual pieces and assembling the scores into the
book. Each individual piece is an `.ily` that only defines the
elements of the score but not the score itself. As such, that means
it is insufficient for compiling on its own.
To test an individual piece, I would comment out some of the parts
within the top-level file so that only the one piece in question is
processed, which saves time while iterating. However, it would be
interesting if I could structure the files in a way that it could be a
standalone file yet still be useful as an include. Maybe something
like this:
%%%%
\version "whatever"
\includeOnce "common.ily" % Bring this file in as needed. %
chordsPieceI = \chordmode { ... }
notesPieceI = \relative c' { ... }
lyricsPieceI = \lyricmode { ... }
\ifNotIncluded { % Do this only if compiled as a standalone. %
\score {
<<
\new ChordNames \chordsPieceI
\new Voice = "notes" \notesPieceI
\new Lyrics \lyricsto "notes" \lyricsPieceI
>>
\layout { ... }
}
}
%%%%
When included, only the variables are defined and the definition of
the score, layout, and what not are the responsibility of the
top-level file. However, if I want to preview just this file, I could
compile it by itself in which case the explicit score definition would
result in output.
You may look at this file:
https://git.openlilylib.org/bfsc/das-trunkne-lied/blob/master/library/ly/makescore/compile-segment.ily
which does more or less what you are looking for.
However, I don't know whether that is at all understandable, especially
on its own. But it might give you an idea.
Urs
But then there is also the issue of the common include file. Normally,
the top-level file would take care of that include so all of the
individual pieces just assume it has been included. To explicitly
include it in each individual piece would mean that it is getting
included and processed multiple times, potentially redefining a
variable multiple times. But it would need to be there when compiling
the individual piece on its own, otherwise the common variables do not
exist.
-- Aaron Hill
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user