On 25 May, 2020, at 12:46 PM, David Wright <lily...@lionunicorn.co.uk> 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 DK's method, it turns out > your goal is something different: to discover all the top-level files > that need to be recompiled when you edit an arbitrary \include file. Not really an A/B problem in that I’m not changing the end goal. I needed (and asked) about A (constructing the list of dependencies) because solving A was the prerequisite for getting make to do B (figuring out which scores needed to be recompiled when I changed a source file). While I briefly toyed with the idea of doing B myself (and indeed, had a proof of concept bash script), Jacques pointing to make just made it clear to me that B was already solved by make, provided I solved A in a make-friendly way. > That means that, having edited a mid- to low-level source file in your > library, you have to search every DEP to see whether that file is > mentioned. This includes those of the "someone" who uses your library. > And all those DEPs must be kept up-to-date if the search is to be > performed correctly. That’s true, but this is something make can do automatically given a rule which defines how to create the DEPs. Since such a rule already exists for doing this with CC -M (and is in the gnumake manual: https://www.gnu.org/software/make/manual/html_node/Automatic-Prerequisites.html#Automatic-Prerequisites), it was fairly trivial for me to adapt that. > The idea behind my later script was: given "some simple rules in your > source layout" and the constituency of your LP sources, the backwards > search for reverse dependencies can be carried out any time any source > file is altered, without the need to keep DEP files up-to-date, > because it greps the active set of files. If I’m understanding you correctly, your point is that A doesn’t need to be solved at all, if you’re willing to solve B in a totally different fashion (i.e. not use make). And I would say that that is true. But it means ignoring the tools that are already at my disposal. While I’m all for learning new things, I hate spending time doing things that someone else has already done if I can use their work. > > Given a top-level .ly file and DK's code, I don't see how you > would avoid any of the recompilng required when you use DK's > output. The last line of the script says > > #(format #t "~{~a\n~^~}" (ly:source-files)) > > How do you use source files without recompiling them—that's what 's > perplexed me all along in this thread. All I've tried to do is give > an idea for finding a list of current top-level files that \include an > arbitrary, specific file. Anyone, with assistance from LP, can make > this as hard as they like for themselves. 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 to construct ly:source-files and then output that list to stdout. It is the equivalent, in some sense, of the -M option for a CC (which is where the whole analogy got started). cc -M sample.c does not create sample.o, it outputs the list of files that sample.o depends on. Likewise lilypond --init parse-only.ly sample.ly does not create sample.pdf, it outputs the list of files that sample.pdf depends on. In both cases we’re using the compiler’s (cc or lilypond) already existing knowledge of how to read its source and find the mentioned includes, but instead of telling it to use that knowledge to create the target (the object file or pdf), we’re telling it to use that knowledge to create the dependency list. ✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝ Fr. Samuel, OSB (R. Padraic Springuel) St. Anselm’s Abbey 4501 South Dakota Ave, NE Washington, DC, 20017 202-269-2300 (c) 202-853-7036 PAX ☧ ΧΡΙΣΤΟΣ