Re: Include path syntax on Mac

[David Wright]

On Thu 23 Aug 2018 at 21:47:51 (+0200), Hans Åberg wrote:
> 
> > On 23 Aug 2018, at 21:12, David Wright <address@hidden> wrote:
> > 
> > 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 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 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.

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

Cheers,
David.