[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-user
Subject:    Re: Include path syntax on Mac
From:       Hans_Åberg <haberg-1 () telia ! com>
Date:       2018-08-23 22:16:48
Message-ID: 20AF13F7-1EF2-46A0-ABBE-5BB3739B8C46 () telia ! com
[Download RAW message or body]


> On 23 Aug 2018, at 23:26, David Wright <lilylis@lionunicorn.co.uk> wrote:
> 
> On Thu 23 Aug 2018 at 21:47:51 (+0200), Hans Åberg wrote:
> > 
> > > > 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 must work which is best for what it does, but if it is not what is expected, \
like when it chooses some other file, it leads to hard to catch errors.

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

Take Bison then, which writes multiple files. Then, running in directory tmp2
   bison -o ../tmp3/parser.cc ../tmp1/parser.yy
reads the input ../tmp1/parser.yy and writes all files where the main output file is, \
in ../tmp3/, and tmp2 remains empty.

So that is, I gather, what you would want with 
  lilypond -o ../tmp3/ ../tmp1/input.ly
but which it doesn't.

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

It may not be a problem for those that only use LilyPond and read the manual very \
carefully. I just note that it is conceptually different from programs like GCC and \
Bison, and from that viewpoint seems to invite hard to catch errors.



_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


[prev in list] [next in list] [prev in thread] [next in thread]