Re: Include path syntax on Mac

[Hans Åberg]

> On 23 Aug 2018, at 23:26, David Wright <address@hidden> wrote:
> 
> On Thu 23 Aug 2018 at 21:47:51 (+0200), Hans Åberg wrote:
>> 
>>>> GCC works like with PATH, using first occurrence only. So the compiler 
>>>> system files can be overridden that way.
>>> 
>>> Yes, but the preprocessor can distinguish the system's #include files
>>> from the user's own ones with <foo> and "foo".
>> 
>> LilyPond does not have that; I have no preferences whether it should.
> 
> I know LP doesn't have that. What I can't discern is whether you
> *expect* the LP commandline to behave just like a GCC one, or whether
> you *want* it to. IOW I couldn't understand the sentiment behind your
> "Normally in compilers, …" about four messages back.

LilyPond must work which is best for what it does, but if it is not what is 
expected, like when it chooses some other file, it leads to hard to catch 
errors.

>>>> LilyPond has system files named like makam.ly, which is natural to use in 
>>>> ones own code. I think that then these are preferred rather than the local 
>>>> ones, which can be confusing.
>>> 
>>> Exactly. The <LP-installation-path>/ly/*.ly files must be available in
>>> order for LP to behave as documented. But unlike with C, they pollute
>>> both the user's library paths *and* the user's source-file paths.
>> 
>> One might get rid of that by adding <…>, and change "…" to first search the 
>> user directory. It would not affect any old lilypond code, I think, because 
>> if there are name clashes as it is now, the user code cannot be run.
>> 
>>>>>>> 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.
>>>> 
>>>> With GCC, only one item after -o belong to this option; additional ones 
>>>> are interpreted without the -o.
>>> 
>>> Sure. LP is the same: you can only write the output to one directory,
>>> or construct output filenames around one basic string. That wasn't my
>>> point. The problem is cd-ing to -o's directory *before* resolving the
>>> paths on the commandline (restating the paragraph above).
>> 
>> GCC does not change the directory trying to pass it to -o as you wrote 
>> above; just a weird error I think.
> 
> Again, I don't understand why you bring up GCC. AIUI GCC writes
> a single file, and -o overrides its default name and location.
> 
> LP is different. It can write many output files, so since 2.14 -o
> allows a directory name. But where you want to place the output
> shouldn't affect the input files at all.

Take Bison then, which writes multiple files. Then, running in directory tmp2
   bison -o ../tmp3/parser.cc ../tmp1/parser.yy
reads the input ../tmp1/parser.yy and writes all files where the main output 
file is, in ../tmp3/, and tmp2 remains empty.

So that is, I gather, what you would want with 
  lilypond -o ../tmp3/ ../tmp1/input.ly
but which it doesn't.

> But summarising to try to avoid misunderstanding of my opinions, I
> think that -I affecting the main input source file is a documented,
> intended misfeature, the -o problem is an undocumented, unintended
> feature, and the ly/foo.ly nameclash problem is something that might
> be unavoidable for -I include files (but not the main input file).

It may not be a problem for those that only use LilyPond and read the manual 
very carefully. I just note that it is conceptually different from programs 
like GCC and Bison, and from that viewpoint seems to invite hard to catch 
errors.