> On 23 May, 2020, at 7:34 PM, David Wright <lily...@lionunicorn.co.uk> 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 possibility of multiple folders with varying levels of hierarchy. The changed file might be in ../ relative to one file, ../../ relative to another, ../some/dir/levels relative to a third and other possible variations. It might also be specified /with/an/absolute/path in some files. All of that complicates the search string for grep. 2) You haven’t accounted for -I options when lilypond is called. Some of the files included might not be in the same directory tree at all. You’ll need access to the list of -I options with which lilypond is called in order to properly identify all the possible top-of-tree/ folders. You might be able to extract what -I flags a particular project has that are specific to it by examining some file in the project folders, but what do you do if that information is stored in a personal shell script or alias setup that catches all lilypond calls and makes sure certain -I flags are added (as might be common for someone using openLilyLib or with a personal library of formatting snippets)? Now your shell script has to go analyze your personal shell script or shell profile. 3) What about the relative-includes option? If an included file includes other files, where are these files located? Is the given path relative to the current file or to the top-level file? Our grep search string is getting even more complicated to account for this. Sure, your ideas would probably catch most cases, and it would be possible to write a shell script that accounted for these complications. But you’re duplicating a whole lot of work that’s already been done. LilyPond itself already knows how to deal with these factors to find the included files (either because it’s built-in or because you’ve already told it what to do when you configured your system). Why reinvent this wheel in a shell script if LilyPond can be made to output what it already knows for you? Another issue: How are you keeping track of which files have changed (and thus should seed your script)? If you recompile frequently after only changing a file or two, it’s fairly easy, but what if the change you’re working on takes several days to (either due to complexity or restricted time) or touches a whole bunch of files? Are you supposed to manually remember all those changes? Or maybe you’re planning on querying your version control system (you are using one, right?) for that information? As a last resort, you might also look at modified times on the pdfs (if they exist) and the source files. Of course, given a proper list of file dependencies, make will do all this work for you. That’s what it is for. Pair make with a LilyPond based tool which can determine dependencies automatically and it becomes even simpler because the system is self-updating. Now, I will grant you, that if LilyPond could not be convinced to output what it knows about file dependencies (and the Frescobaldi project hadn’t written python-ly which has the include_args() command in the ly.slexer module), then I probably would have written a shell script like you describe to get the dependencies information (or, more likely, to just do the recompiling itself and not bothered with make at all). However, once David K. showed that it was possible for LilyPond to output that information (and even better, without going through all the work necessary to produce a score at the same time) it makes the most logical sense to me to use that rather than start from scratch with a shell script (or start from include_args() in python-ly to write a Python script). ✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝ 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 ☧ ΧΡΙΣΤΟΣ
