Re: Include path syntax on Mac

[David Wright]

On Thu 16 Aug 2018 at 10:13:42 (+0200), Hans Åberg wrote:
> > On 16 Aug 2018, at 02:27, David Wright <address@hidden> wrote:
> > On Wed 15 Aug 2018 at 22:40:57 (+0200), Hans Åberg wrote:
> >>> On 15 Aug 2018, at 21:49, David Wright <address@hidden> 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.

Yes, that's why I was happy to attempt to compile a defective source
file when I last researched this, in order to make an unambiguous distinction.

> > 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.

I'm not sure that is how LP is intended to work. I think the idea
would be that you redefine or override the assignments made by those
files if you want to change things and to do that, your files need
to run after LP's rather than preventing their interpretation entirely.

> > 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.

I think -o *is* resolved relative to the current directory if it's a
relative path. The problem is that given, say:

~/here $ lilypond -o ../there/ source.ly

the output looks like:

GNU LilyPond 2.19.82
Changing working directory to: `../there'
Processing `source.ly'
Parsing...
/usr/share/lilypond/2.19.82/ly/init.ly:43:1: error: cannot find file: 
`source.ly'

which implies that LP is trying to find here/../there/source.ly instead
of here/source.ly which is what the user intended. LP needs to resolve
all the relative paths on the commandline from $PWD *before* it
changes the value of $PWD itself.

Cheers,
David.