Re: Need help creating Scheme functions to automate includes of many scores in a project

[Urs Liska]

Am 26.06.2018 um 01:25 schrieb Aaron Hill:
> On 2018-06-25 15:51, David Kastrup wrote:
> > Nah <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user