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". 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 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). Cheers, David. _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
