Hello there, I know some LilyPond code editors (like Frescobaldi) have to reverse engineer the LilyPond music files to figure out what it /should/ be looking for as far as what files where actually generated by LilyPond.
I happen to rely a lot on code based on something like : \version "2.19.58" #(ly:book-process (ly:make-book $defaultpaper $defaultheader #{ \score {c'} #}) $defaultpaper $defaultlayout "ThisIsThePDFFileName") …recursively generating lots of book from a list of different instruments with each different editions to engrave. Well Frescobaldi for one has no clue of what is going on and for obvious reasons. I suppose one could generate PDF filenames based on the time and date for all I know. So, as mentioned in this thread : https://github.com/wbsoft/frescobaldi/issues/546 Could a possible solution be for LilyPond to produce a manifest file at compilation? The manifest file could be set as an option at compilation so that editors could reliably find said manifest. It would then be trivial to read that manifest of produced files at the end of compilation. I suppose this compiler manifest could be plain text and in a easily digestible format (e.g. one file per line). ./music.pdf ./music.svg ./music.midi As a workaround, I am currently using 2 systems one being a set of scheme functions to publish final work and my old system of explicitly commenting %{%} \book blocks in some file as I need work on them. What are your thoughts on this? Should it not be LilyPond responsibility to report what it has done? -- Pierre-Luc Gauthier _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user