On Tue, Sep 10, 2013 at 5:22 AM, immanuel litzroth <ilitzr...@gmail.com>wrote:

> If there were some kind of make-dep for lilypond it could even generate
> these dependencies
> automaticaly, like it happens for C (the compiler generates dependencies
> when passed the
> correct flags). This should not be too hard to brew up?
> Immanuel
>
>
> On Tue, Sep 10, 2013 at 10:47 AM, Jacques Menu <jacques.m...@tvtmail.ch>wrote:
>
>> Hello Carl,
>>
>> An approach could be to create a makefile containing:
>>         - the rules to compile LP files to PDF (fixed part);
>>         - the dependencies among LP files reflecting the presence of
>> \include in them (variable part).
>>
>> Producing the makefile could be done by a script when your dropbox
>> changes, and you could then call "make" to compile whatever needs to be.
>>
>> JM
>>
>> Le 10 sept. 2013 à 10:04:54, ArnoldTheresius <arnold.we...@siemens.com>
>> a écrit :
>> > I allready made a C program for Windows, which does a limited 'follow
>> the
>> > \include files' to examine the file dates. Finally it starts lilypond
>> > (command line) if one of the source files found is newer than the
>> resulting
>> > PDF, otherwise it prompts for the question 'compile or not?'.
>> > This program is limited to
>> > - only files (source and result) in the current working directory are
>> > examined
>> > - the \include command must be the only one in the line (white space
>> only
>> > allowed at the left), exactly one space to the string start '"'
>> character
>> > - \include commands inside a comment block ( '%{' to '%}' ) will be
>> > examined, too.
>> >
>> > Unfortunately, this program is specialized for my use. I did try (but
>> not
>> > complete) to implement some special features. There is very little
>> > documentation in the source code.
>> > Only if you have some experiance in C programming the source code can
>> help -
>> > but an experianced C programmer might be faster to build his own
>> 'ly-newer'
>> > command line program form scratch than by extending my program.
>> >
>> > Feel free to ask for the C source code, if you are still interested.
>> >
>>
>
These are along the lines of what I was thinking of. I don't have any
experience with C. My programming experience as of late is in PHP. So I
gave some thought last night to using it to read the files and trace the
\include dependencies. I haven't had a chance to put any code down, but
I'll probably take a look at that option.

The thing that was undesirable on the makefile idea in general is that
having to maintain a makefile seems like an unnecessary redundancy. That
is, not only do I have to reference these files in the actual LilyPond
sources, but also make sure that I add the dependency information to this
other file. This seems like it would lead to synchronization issues if I
change which file I use in the .ly file, but not the makefile.

What I'm considering from the dynamic makefile angle (which I hadn't
considered prior to this discussion) is to have a trigger on all the
subfolders that will pass the file name to php, which will follow the known
dependency paths (music and lyrics to setting, setting to target format) to
build a list of files which need to be recompiled. I suppose I could call
lilypond from the php code, but I could also theoretically have it
construct the makefile. This would overcome the possible race condition
that exists if I use cascading monitors on each folder (for example, if I
update a global file, every final output file would need to be recompiled,
but if I use a touch command to trigger updates, I think some would be
missed.

The other advantage with PHP is that hopefully and eventually, this is
going to go to a database-driven workflow using PHP, where definitions are
all going to database entries to be generated on the fly as anything is
updated.

Regards,
Carl
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to