> On 16 Aug 2018, at 02:27, David Wright <[email protected]> wrote: > > On Wed 15 Aug 2018 at 22:40:57 (+0200), Hans Åberg wrote: >> >>> On 15 Aug 2018, at 21:49, David Wright <[email protected]> wrote: >>> >>> On Wed 15 Aug 2018 at 10:07:11 (+0200), Hans Åberg wrote: >>>> >>>> Also, it seems it adds the directory before the current in the call >>>> argument. Normally in compilers, one would expect -I to only affect input >>>> directives occurring in files, I think. >>> >>> I'm not quite sure what you're saying here. Do you mean that >>> >>> lilypond -I ~/LilyLib source.ly >>> >>> is interpreted as meaning >>> >>> lilypond -I ~/LilyLib ~/LilyLib/source.ly >>> >>> in MacOS? >> >> Yes. So a file ./source.ly in the current directory won't be compiled, only >> if the file ~/LilyLib/source.ly does not exist. >> >> I would have expected that -I only affects \include within the file >> ./source.ly and others, and not the command line itself, like in GCC. > > Yes, that's what I would expect too, though the way the manuals are > written, their defence could be that it says "input files", not > "include files".
The problem is that it is hard to detect errors when it compiles another file than the one expected. > So long as your source directory is relatively clean, a trivial > workaround would be seem to be to start each invocation with: > > $ lilypond -I. > > but even that has a limited effect because there is another, hidden, > -I that comes even earlier: LP's own files, as reported in > http://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00717.html There I would expect -I to be put ahead of the program system directories, so those latter can be overridden. I think GCC in the past may have had another behavior, and GCC 8 maybe added more options to regulate in detail. > Compounded with the problems caused by -o, there's probably every > reason to use an absolute path for the LP input file, particularly > in scripts. Perhaps the file handling could be revamped when the > major change in relative-includes is made (from #f to #t). Also -o I would expect to be relative the current directory. Autotools would expect that: if one compiles out of the source directory, then the generated files should normally end up in the build directory. _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
