[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Include path syntax on Mac
From: |
Hans Åberg |
Subject: |
Re: Include path syntax on Mac |
Date: |
Thu, 23 Aug 2018 21:47:51 +0200 |
> 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.
>> 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.
- Re: Include path syntax on Mac, (continued)
- Re: Include path syntax on Mac, Hans Åberg, 2018/08/14
- Re: Include path syntax on Mac, Urs Liska, 2018/08/14
- Re: Include path syntax on Mac, Hans Åberg, 2018/08/15
- Re: Include path syntax on Mac, David Wright, 2018/08/15
- Re: Include path syntax on Mac, Hans Åberg, 2018/08/15
- Re: Include path syntax on Mac, David Wright, 2018/08/15
- Re: Include path syntax on Mac, Hans Åberg, 2018/08/16
- Re: Include path syntax on Mac, David Wright, 2018/08/16
- Re: Include path syntax on Mac, Hans Åberg, 2018/08/16
- Re: Include path syntax on Mac, David Wright, 2018/08/23
- Re: Include path syntax on Mac,
Hans Åberg <=
- Re: Include path syntax on Mac, David Wright, 2018/08/23
- Re: Include path syntax on Mac, Hans Åberg, 2018/08/23