Re: Identify included files

[Fr. Samuel Springuel]

On 25 May, 2020, at 12:46 PM, David Wright <address@hidden> 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 ☧ ΧΡΙΣΤΟΣ