Re: Include path syntax on Mac

[David Wright]

On Thu 16 Aug 2018 at 22:55:29 (+0200), Hans Åberg wrote:
> > On 16 Aug 2018, at 22:35, David Wright <address@hidden> wrote:
> > 
> >> 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.
> 
> 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 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.

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

Cheers,
David.