On 09/06/2020 15:57, Fr. Samuel Springuel wrote:
On 9 Jun, 2020, at 5:54 AM, Matt Wallis wrote:
I found https://lists.gnu.org/archive/html/lilypond-user/2020-05/msg00148.html
very interesting.
It describes how to get lilypond to print out dependencies. Have you looked
into this?
That’s
> On 9 Jun, 2020, at 5:54 AM, Matt Wallis wrote:
>
> I found
> https://lists.gnu.org/archive/html/lilypond-user/2020-05/msg00148.html very
> interesting.
> It describes how to get lilypond to print out dependencies. Have you looked
> into this?
That’s from the start of this thread and I’m
On 09/06/2020 10:54, Matt Wallis wrote:
Include the backslash when you define a directory (as above).
s/backslash/slash/
On 06/06/2020 16:34, Fr. Samuel Springuel wrote:
I have now updated the repository I posted earlier
(https://github.com/rpspringuel/lilypond_make) to contain two additional
branches:
GNUmake_dependencies: Implements dependency generation as described in the
GNUmake manual
I have now updated the repository I posted earlier
(https://github.com/rpspringuel/lilypond_make) to contain two additional
branches:
GNUmake_dependencies: Implements dependency generation as described in the
GNUmake manual
mad-scientist_dependencies: Implements dependency generation as
> On 26 May, 2020, at 6:13 PM, David Wright wrote:
>
> Because of the inability to collate multiple MIDI files, I've always
> renamed them. I tee the log into a nonce file, which I grep for their
> names in a postprocessing script. (I then trash the log unless there
> was an error code, in which
On Tue 26 May 2020 at 13:06:50 (-0400), Fr. Samuel Springuel wrote:
> > On 26 May, 2020, at 12:09 PM, Timothy Lanfear wrote:
> >
> > Maybe this code can give some hints on how to decide if midi is being
> > produced.
>
> That’s the first code I’ve seen that’s been able to definitively show
> On 26 May, 2020, at 12:09 PM, Timothy Lanfear wrote:
>
> Maybe this code can give some hints on how to decide if midi is being
> produced.
That’s the first code I’ve seen that’s been able to definitively show when a
midi file is being produced. Thank you.
Now, there is the issue of it
On 26/05/2020 16:15, Fr. Samuel Springuel wrote:
I’ve already accounted for this in my most recent version of
parse-only.ly. It’s not as straight forward as ly:source-files but by
looking at (ly:get-option 'backend), (ly:get-option 'aux-files),
(ly:parser-output-name) and (ly:output-formats),
> On 26 May, 2020, at 6:18 AM, Matt Wallis wrote:
>
> For C/C++, there is an excellent discussion of the issues about automatically
> producing dependencies and dealing with them in make:
>
> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
>
> I think much of this is
> Le 15 mai 2020 à 18:03, Fr. Samuel Springuel a écrit :
>
>> On 15 May, 2020, at 3:43 AM, Valentin Villenave wrote:
>>
>> On 5/15/20, Fr. Samuel Springuel wrote:
>>> Before I start writing a script to do this, is there an existing
tool which
>>> will identify all the `\include` files that a
> On 25 May, 2020, at 3:12 PM, Wols Lists wrote:
>
> So. Am I correct in thinking that, if you change one .ily file, you need
> to rebuild the entire makefile? WHY?
> And it means if put a new include into
> dynamics.ily, I just need to create/update the line for dynamics.ily,
> and everything
On 25/05/20 19:25, Fr. Samuel Springuel wrote:
> I think this is where you’ve missed something. When using DK’s code as the
> init file (or my later version, which make the output more make-friendly),
> LilyPond **does not actually typeset the music.** All it does is read
> through the files
On 25 May, 2020, at 12:46 PM, David Wright wrote:
> But it seems to me that your OP had the makings of an A/B problem.
> You originally asked for a script that worked in the forward
> direction: a list of top-level file's dependencies, for constructing
> DEP. Having got LP to perform that with
On Sun 24 May 2020 at 16:28:53 (-0400), Fr. Samuel Springuel wrote:
> > On 23 May, 2020, at 7:34 PM, David Wright wrote:
> >
> > If you follow some simple rules in your source layout, constructing
> > such a list might be most straightforward to do in the shell, using
> > grep.
>
> It’s not
On 5/25/20, R. Padraic Springuel wrote:
> It depends on the state of the relative-includes variable. If true, then
> paths are relative to the file in which the include statement appears. If
> false, the paths are relative to the main input file. Default behavior is
> false.
Careful, the
> On May 25, 2020, at 2:58 AM, Wols Lists wrote:
>
> On 24/05/20 21:28, Fr. Samuel Springuel wrote:
>> It’s not quite as straight-forward as you seem to think:
>>
>> 1) You haven’t accounted for the possibility of multiple folders with
>> varying levels of hierarchy. The changed file might
On 24/05/20 21:28, Fr. Samuel Springuel wrote:
> It’s not quite as straight-forward as you seem to think:
>
> 1) You haven’t accounted for the possibility of multiple folders with varying
> levels of hierarchy. The changed file might be in ../ relative to one file,
> ../../ relative to
> On 23 May, 2020, at 7:34 PM, David Wright wrote:
>
> If you follow some simple rules in your source layout, constructing
> such a list might be most straightforward to do in the shell, using
> grep.
It’s not quite as straight-forward as you seem to think:
1) You haven’t accounted for the
On Thu 21 May 2020 at 13:10:40 (-0400), Fr. Samuel Springuel wrote:
> > On 21 May, 2020, at 9:36 AM, David Kastrup wrote:
> > antlists writes:
> >> On 21/05/2020 01:49, David Wright wrote:
> >>> I don't understand your equivalence between .ily and .h files. The
> >>> .ily file(s) can contain
On Fri 22 May 2020 at 12:12:17 (+0100), Wols Lists wrote:
> On 22/05/20 02:08, David Wright wrote:
> > On Thu 21 May 2020 at 17:54:38 (+0100), antlists wrote:
> >> On 21/05/2020 16:36, David Wright wrote:
> >>> On Thu 21 May 2020 at 13:57:00 (+0100), antlists wrote:
>
> >> I have tried
On 23/05/2020 06:06, Michael Gerdau wrote:
Big deal. I won't ask what's in voiceTrombone.ily.
A variable declaration. You know - EXACTLY THE SAME as C programmers
often stick in .h files ...
I don’t think that’s correct.
For one according to my understanding LP has no variable
>> Big deal. I won't ask what's in voiceTrombone.ily.
>
> A variable declaration. You know - EXACTLY THE SAME as C programmers
> often stick in .h files ...
I don’t think that’s correct.
For one according to my understanding LP has no variable declarations
whatsoever, only definitions.
For
> On 21 May, 2020, at 9:08 PM, David Wright wrote:
>
> Look¹, I'm not the one making this analogy. I'm trying to make any
> sense of it, and why this "dependency file" is being built.
Well, perhaps it’s time to drop the analogy then and work with an example. For
reference sake, let’s use the
On 22/05/20 02:08, David Wright wrote:
> On Thu 21 May 2020 at 17:54:38 (+0100), antlists wrote:
>> On 21/05/2020 16:36, David Wright wrote:
>>> On Thu 21 May 2020 at 13:57:00 (+0100), antlists wrote:
>
>> I have tried accidentally
>> to do things like "lilypond voiceTrombone.ily" and it blew up
On Thu 21 May 2020 at 17:54:38 (+0100), antlists wrote:
> On 21/05/2020 16:36, David Wright wrote:
> > On Thu 21 May 2020 at 13:57:00 (+0100), antlists wrote:
> > > On 21/05/2020 01:49, David Wright wrote:
> > > > I don't understand your equivalence between .ily and .h files. The
> > > > .ily
On 21/05/2020 16:36, David Wright wrote:
On Thu 21 May 2020 at 13:57:00 (+0100), antlists wrote:
On 21/05/2020 01:49, David Wright wrote:
I don't understand your equivalence between .ily and .h files. The
.ily file(s) can contain just as much code as the .ly file(s), whereas
.h files don't
> On 21 May, 2020, at 9:36 AM, David Kastrup wrote:
>
> antlists writes:
>
>> On 21/05/2020 01:49, David Wright wrote:
>>> I don't understand your equivalence between .ily and .h files. The
>>> .ily file(s) can contain just as much code as the .ly file(s), whereas
>>> .h files don't contain
On Thu 21 May 2020 at 13:57:00 (+0100), antlists wrote:
> On 21/05/2020 01:49, David Wright wrote:
> > I don't understand your equivalence between .ily and .h files. The
> > .ily file(s) can contain just as much code as the .ly file(s), whereas
> > .h files don't contain any code at all (in the
On 21/05/2020 14:36, David Kastrup wrote:
antlists writes:
On 21/05/2020 01:49, David Wright wrote:
I don't understand your equivalence between .ily and .h files. The
.ily file(s) can contain just as much code as the .ly file(s), whereas
.h files don't contain any code at all (in the sense
antlists writes:
> On 21/05/2020 01:49, David Wright wrote:
>> I don't understand your equivalence between .ily and .h files. The
>> .ily file(s) can contain just as much code as the .ly file(s), whereas
>> .h files don't contain any code at all (in the sense of producing
>> executable code for
On 21/05/2020 01:49, David Wright wrote:
I don't understand your equivalence between .ily and .h files. The
.ily file(s) can contain just as much code as the .ly file(s), whereas
.h files don't contain any code at all (in the sense of producing
executable code for the next stage.
a) just like
On Mon 18 May 2020 at 14:32:31 (-0400), Fr. Samuel Springuel wrote:
> > On 18 May, 2020, at 11:30 AM, David Wright
> > wrote:
> >
> > If you were compiling a C program foo.c into an executable, what you
> > would be trying to avoid is recompiling fnbar.c into fnbar.o over
> > and over again
> On 20 May, 2020, at 12:05 PM, Fr. Samuel Springuel
> wrote:
>
> Use of the -dbackend=eps (or setting the backend to eps in the file) also
> causes the production of several other files (*-systems.tex, *-systems.texi,
> *-systems.count, and the eps and pdf files for each system) while -E (or
As an exercise in Scheme programming (and because I’m something of a
perfectionist), I’m working on improving the output when using parse-only.ly by
having it account for `--format` flags and the various backends when
constructing the target portion of the make rule (the version I previously
> On 18 May, 2020, at 11:30 AM, David Wright wrote:
>
> If you were compiling a C program foo.c into an executable, what you
> would be trying to avoid is recompiling fnbar.c into fnbar.o over
> and over again (and all of its similar companions).
>
> Can you explain which of your files are the
On 18/05/2020 15:29, Fr. Samuel Springuel wrote:
On 18 May, 2020, at 9:37 AM, antlists wrote:
define trombone-notes.ly as a target, define it as changed if its dependencies change,
and say "it doesn't exist as a file that can be created with a command".
Right, that’s the step I’m trying
Am Montag, den 18.05.2020, 10:35 -0500 schrieb David Wright:
> On Fri 15 May 2020 at 12:03:33 (-0400), Fr. Samuel Springuel wrote:
> > > On 5/15/20, Fr. Samuel Springuel wrote:
> > > > Before I start writing a script to do this, is there an
> > > > existing tool which
> > > > will identify all
On Fri 15 May 2020 at 12:03:33 (-0400), Fr. Samuel Springuel wrote:
> > On 5/15/20, Fr. Samuel Springuel wrote:
> >> Before I start writing a script to do this, is there an existing tool which
> >> will identify all the `\include` files that a LilyPond file depends on?
> >> Even better, one that
On Mon 18 May 2020 at 10:29:22 (-0400), Fr. Samuel Springuel wrote:
> > On 18 May, 2020, at 9:37 AM, antlists wrote:
> >
> > define trombone-notes.ly as a target, define it as changed if its
> > dependencies change, and say "it doesn't exist as a file that can be
> > created with a command".
>
> On 18 May, 2020, at 9:37 AM, antlists wrote:
>
> define trombone-notes.ly as a target, define it as changed if its
> dependencies change, and say "it doesn't exist as a file that can be created
> with a command".
Right, that’s the step I’m trying to automate. Make itself cannot determine
Am Montag, den 18.05.2020, 14:37 +0100 schrieb antlists:
> On 18/05/2020 13:44, David Kastrup wrote:
> > antlists writes:
> >
> > > On 15/05/2020 21:17, Fr. Samuel Springuel wrote:
> > > > Now I just need to turn this list into something that can be
> > > > used to
> > > > figure out if the
On 18/05/2020 13:44, David Kastrup wrote:
antlists writes:
On 15/05/2020 21:17, Fr. Samuel Springuel wrote:
Now I just need to turn this list into something that can be used to
figure out if the target needs to be recompiled.
As Jacques said, "make".
At the top of your directory structure
antlists writes:
> On 15/05/2020 21:17, Fr. Samuel Springuel wrote:
>> Now I just need to turn this list into something that can be used to
>> figure out if the target needs to be recompiled.
>
> As Jacques said, "make".
>
> At the top of your directory structure you can have a makefile, and it
On 15/05/2020 21:17, Fr. Samuel Springuel wrote:
Now I just need to turn this list into something that can be used to figure out
if the target needs to be recompiled.
As Jacques said, "make".
At the top of your directory structure you can have a makefile, and it
just contains a list of all
"Fr. Samuel Springuel" writes:
>> On 16 May, 2020, at 5:31 PM, David Kastrup wrote:
>>
>> The problem is that there are quite a few things in there that make no
>> overwhelming sense for the task you want to solve. In order to allow
>> for "snappy" init files doing specific tasks like this
> On 16 May, 2020, at 5:31 PM, David Kastrup wrote:
>
> The problem is that there are quite a few things in there that make no
> overwhelming sense for the task you want to solve. In order to allow
> for "snappy" init files doing specific tasks like this version of
> parse-only.ly does, one
"Fr. Samuel Springuel" writes:
>> On 15 May, 2020, at 5:04 PM, David Kastrup wrote:
>>
>> "Fr. Samuel Springuel" writes:
>>
>>> Before I start writing a script to do this, is there an existing tool
>>> which will identify all the `\include` files that a LilyPond file
>>> depends on? Even
> On 15 May, 2020, at 5:04 PM, David Kastrup wrote:
>
> "Fr. Samuel Springuel" writes:
>
>> Before I start writing a script to do this, is there an existing tool
>> which will identify all the `\include` files that a LilyPond file
>> depends on? Even better, one that will work in a recursive
"Fr. Samuel Springuel" writes:
> Before I start writing a script to do this, is there an existing tool
> which will identify all the `\include` files that a LilyPond file
> depends on? Even better, one that will work in a recursive fashion?
You can use a file like
%% Toplevel initialisation
> On 15 May, 2020, at 12:03 PM, Fr. Samuel Springuel
> wrote:
>
>> On 15 May, 2020, at 3:43 AM, Valentin Villenave
>> wrote:
>>
>> On 5/15/20, Fr. Samuel Springuel wrote:
>>> Before I start writing a script to do this, is there an existing tool which
>>> will identify all the `\include`
Hello Samuel,
The tool you’re looking for to track changed files and re-handle them is ‘make’.
JM
> Le 15 mai 2020 à 18:03, Fr. Samuel Springuel a écrit :
>
>> On 15 May, 2020, at 3:43 AM, Valentin Villenave
>> wrote:
>>
>> On 5/15/20, Fr. Samuel Springuel wrote:
>>> Before I start
> On 15 May, 2020, at 3:43 AM, Valentin Villenave
> wrote:
>
> On 5/15/20, Fr. Samuel Springuel wrote:
>> Before I start writing a script to do this, is there an existing tool which
>> will identify all the `\include` files that a LilyPond file depends on?
>> Even better, one that will work in
On 5/15/20, Fr. Samuel Springuel wrote:
> Before I start writing a script to do this, is there an existing tool which
> will identify all the `\include` files that a LilyPond file depends on?
> Even better, one that will work in a recursive fashion?
Since 2.19.39, you can simply use this:
Am 15. Mai 2020 03:21:55 MESZ schrieb "Fr. Samuel Springuel"
:
>Before I start writing a script to do this, is there an existing tool
>which will identify all the `\include` files that a LilyPond file
>depends on? Even better, one that will work in a recursive fashion?
I know of Frescobaldi
55 matches
Mail list logo
