Re: Include path syntax on Mac

[Hans Åberg]

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

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