lilypond-user
[Top][All Lists]
Advanced

[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, 16 Aug 2018 22:55:29 +0200


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

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.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]