On Thu 16 Aug 2018 at 22:55:29 (+0200), Hans Åberg wrote: > > On 16 Aug 2018, at 22:35, David Wright <lily...@lionunicorn.co.uk> 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. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user