Re: Include path syntax on Mac
> On 23 Aug 2018, at 23:26, David Wright 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 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 /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
Re: Include path syntax on Mac
On Thu 23 Aug 2018 at 21:47:51 (+0200), Hans Åberg wrote: > > > On 23 Aug 2018, at 21:12, David Wright wrote: > > > > On Thu 16 Aug 2018 at 22:55:29 (+0200), Hans Åberg wrote: > >>> On 16 Aug 2018, at 22:35, David Wright 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 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 /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. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
> On 23 Aug 2018, at 21:12, David Wright wrote: > > On Thu 16 Aug 2018 at 22:55:29 (+0200), Hans Åberg wrote: >>> On 16 Aug 2018, at 22:35, David Wright 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 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 /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. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
On Thu 16 Aug 2018 at 22:55:29 (+0200), Hans Åberg wrote: > > On 16 Aug 2018, at 22:35, David Wright 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 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 /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
Re: Include path syntax on Mac
> On 16 Aug 2018, at 22:35, David Wright 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. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
On Thu 16 Aug 2018 at 10:13:42 (+0200), Hans Åberg wrote: > > On 16 Aug 2018, at 02:27, David Wright wrote: > > On Wed 15 Aug 2018 at 22:40:57 (+0200), Hans Åberg wrote: > >>> On 15 Aug 2018, at 21:49, David Wright wrote: > >>> On Wed 15 Aug 2018 at 10:07:11 (+0200), Hans Åberg wrote: > > Also, it seems it adds the directory before the current in the call > argument. Normally in compilers, one would expect -I to only affect > input directives occurring in files, I think. > >>> > >>> I'm not quite sure what you're saying here. Do you mean that > >>> > >>> lilypond -I ~/LilyLib source.ly > >>> > >>> is interpreted as meaning > >>> > >>> lilypond -I ~/LilyLib ~/LilyLib/source.ly > >>> > >>> in MacOS? > >> > >> Yes. So a file ./source.ly in the current directory won't be compiled, > >> only if the file ~/LilyLib/source.ly does not exist. > >> > >> I would have expected that -I only affects \include within the file > >> ./source.ly and others, and not the command line itself, like in GCC. > > > > Yes, that's what I would expect too, though the way the manuals are > > written, their defence could be that it says "input files", not > > "include files". > > The problem is that it is hard to detect errors when it compiles another file > than the one expected. Yes, that's why I was happy to attempt to compile a defective source file when I last researched this, in order to make an unambiguous distinction. > > So long as your source directory is relatively clean, a trivial > > workaround would be seem to be to start each invocation with: > > > > $ lilypond -I. > > > > but even that has a limited effect because there is another, hidden, > > -I that comes even earlier: LP's own files, as reported in > > http://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00717.html > > 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. > > 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. Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
> On 16 Aug 2018, at 02:27, David Wright wrote: > > On Wed 15 Aug 2018 at 22:40:57 (+0200), Hans Åberg wrote: >> >>> On 15 Aug 2018, at 21:49, David Wright wrote: >>> >>> On Wed 15 Aug 2018 at 10:07:11 (+0200), Hans Åberg wrote: Also, it seems it adds the directory before the current in the call argument. Normally in compilers, one would expect -I to only affect input directives occurring in files, I think. >>> >>> I'm not quite sure what you're saying here. Do you mean that >>> >>> lilypond -I ~/LilyLib source.ly >>> >>> is interpreted as meaning >>> >>> lilypond -I ~/LilyLib ~/LilyLib/source.ly >>> >>> in MacOS? >> >> Yes. So a file ./source.ly in the current directory won't be compiled, only >> if the file ~/LilyLib/source.ly does not exist. >> >> I would have expected that -I only affects \include within the file >> ./source.ly and others, and not the command line itself, like in GCC. > > Yes, that's what I would expect too, though the way the manuals are > written, their defence could be that it says "input files", not > "include files". The problem is that it is hard to detect errors when it compiles another file than the one expected. > So long as your source directory is relatively clean, a trivial > workaround would be seem to be to start each invocation with: > > $ lilypond -I. > > but even that has a limited effect because there is another, hidden, > -I that comes even earlier: LP's own files, as reported in > http://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00717.html 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. > 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. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
On Wed 15 Aug 2018 at 22:40:57 (+0200), Hans Åberg wrote: > > > On 15 Aug 2018, at 21:49, David Wright wrote: > > > > On Wed 15 Aug 2018 at 10:07:11 (+0200), Hans Åberg wrote: > >> > >> Also, it seems it adds the directory before the current in the call > >> argument. Normally in compilers, one would expect -I to only affect input > >> directives occurring in files, I think. > > > > I'm not quite sure what you're saying here. Do you mean that > > > >lilypond -I ~/LilyLib source.ly > > > > is interpreted as meaning > > > >lilypond -I ~/LilyLib ~/LilyLib/source.ly > > > > in MacOS? > > Yes. So a file ./source.ly in the current directory won't be compiled, only > if the file ~/LilyLib/source.ly does not exist. > > I would have expected that -I only affects \include within the file > ./source.ly and others, and not the command line itself, like in GCC. Yes, that's what I would expect too, though the way the manuals are written, their defence could be that it says "input files", not "include files". So long as your source directory is relatively clean, a trivial workaround would be seem to be to start each invocation with: $ lilypond -I. but even that has a limited effect because there is another, hidden, -I that comes even earlier: LP's own files, as reported in http://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00717.html 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). Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
> On 15 Aug 2018, at 21:49, David Wright wrote: > > On Wed 15 Aug 2018 at 10:07:11 (+0200), Hans Åberg wrote: >> >> Also, it seems it adds the directory before the current in the call >> argument. Normally in compilers, one would expect -I to only affect input >> directives occurring in files, I think. > > I'm not quite sure what you're saying here. Do you mean that > >lilypond -I ~/LilyLib source.ly > > is interpreted as meaning > >lilypond -I ~/LilyLib ~/LilyLib/source.ly > > in MacOS? Yes. So a file ./source.ly in the current directory won't be compiled, only if the file ~/LilyLib/source.ly does not exist. I would have expected that -I only affects \include within the file ./source.ly and others, and not the command line itself, like in GCC. https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Preprocessor-Options.html#Preprocessor-Options https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Directory-Options.html#Directory-Options ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
On Wed 15 Aug 2018 at 10:07:11 (+0200), Hans Åberg wrote: > > > On 15 Aug 2018, at 00:59, Urs Liska wrote: > > > > Am 15.08.2018 um 00:34 schrieb Hans Åberg: > >>> On 14 Aug 2018, at 21:31, Urs Liska wrote: > >>> > >>> Could someone please test (or tell me directly) whether it makes a > >>> difference if a path passed to -I has a trailing slash or not on Mac? > >> It seems to not matter, tried on MacOS 10.13.6. > > > > That was what I expected. Thank you for testing > > You are welcome. > > Also, it seems it adds the directory before the current in the call argument. > Normally in compilers, one would expect -I to only affect input directives > occurring in files, I think. I'm not quite sure what you're saying here. Do you mean that lilypond -I ~/LilyLib source.ly is interpreted as meaning lilypond -I ~/LilyLib ~/LilyLib/source.ly in MacOS? Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
> On 15 Aug 2018, at 18:44, David Kastrup wrote: > > Hans Åberg writes: > >>> On 15 Aug 2018, at 17:05, David Kastrup wrote: >>> >>> C++11 would give us I think? Which should be >>> good for most path manipulations. At least I think so. >> >> It was added in C++17 [1]. GCC 7 or later have -std=c++17. GCC 6 or >> later have C++14 as default, without the -std option. >> >> 1. https://en.cppreference.com/w/cpp/filesystem > > I was talking about , not . That is not part of the standard, so it depends on the compiler [1]. Apple inhouse clang has that for optional even though accepting -std=c++17, so I switched to clang6, where it is properly implemented. 1. https://en.cppreference.com/w/cpp/experimental ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
Hans Åberg writes: >> On 15 Aug 2018, at 17:05, David Kastrup wrote: >> >> C++11 would give us I think? Which should be >> good for most path manipulations. At least I think so. > > It was added in C++17 [1]. GCC 7 or later have -std=c++17. GCC 6 or > later have C++14 as default, without the -std option. > > 1. https://en.cppreference.com/w/cpp/filesystem I was talking about , not . -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
> On 15 Aug 2018, at 17:05, David Kastrup wrote: > > C++11 would give us I think? Which should be > good for most path manipulations. At least I think so. It was added in C++17 [1]. GCC 7 or later have -std=c++17. GCC 6 or later have C++14 as default, without the -std option. 1. https://en.cppreference.com/w/cpp/filesystem ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
David Wright writes: > On Tue 14 Aug 2018 at 21:31:18 (+0200), Urs Liska wrote: >> Hi all, >> >> it seems LilyPond on Windows requires paths passed to the -I command >> line option to have a trailing slash while LilyPond on Linux doesn't >> seem to care whether there is or not (see >> https://github.com/wbsoft/frescobaldi/issues/1094). It seems a fix >> to the issue in Frescobaldi is to ensure there's a trailing slash to >> the paths, which makes it work on Windows and Linux. >> >> Before merging this code I'd need to know whether Mac also doesn't >> care about the trailing slash. Obviously it accepts paths without >> slashes, but if it should not accept them *with* slashes I'd need to >> make the changed code aware of the OS. >> >> Could someone please test (or tell me directly) whether it makes a >> difference if a path passed to -I has a trailing slash or not on >> Mac? > > It's worth bearing in mind that AFAICT -I can take a relative path. > In windows, D: and D:\ can be different directories depending on > circumstances. No idea about the Mac, though. > > Is LP constructing filenames merely by concatenating part1, delimiter > and part2? This usually works but isn't the Right Way, hence functions > like Python's os.path.join(). C++11 would give us I think? Which should be good for most path manipulations. At least I think so. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
> On 15 Aug 2018, at 00:59, Urs Liska wrote: > > Am 15.08.2018 um 00:34 schrieb Hans Åberg: >>> On 14 Aug 2018, at 21:31, Urs Liska wrote: >>> >>> Could someone please test (or tell me directly) whether it makes a >>> difference if a path passed to -I has a trailing slash or not on Mac? >> It seems to not matter, tried on MacOS 10.13.6. > > That was what I expected. Thank you for testing You are welcome. Also, it seems it adds the directory before the current in the call argument. Normally in compilers, one would expect -I to only affect input directives occurring in files, I think. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
On Wed 15 Aug 2018 at 00:58:51 (+0200), Urs Liska wrote: > Am 14.08.2018 um 22:21 schrieb David Wright: > >On Tue 14 Aug 2018 at 21:31:18 (+0200), Urs Liska wrote: > >>Hi all, > >> > >>it seems LilyPond on Windows requires paths passed to the -I command > >>line option to have a trailing slash while LilyPond on Linux doesn't > >>seem to care whether there is or not (see > >>https://github.com/wbsoft/frescobaldi/issues/1094). It seems a fix > >>to the issue in Frescobaldi is to ensure there's a trailing slash to > >>the paths, which makes it work on Windows and Linux. > >> > >>Before merging this code I'd need to know whether Mac also doesn't > >>care about the trailing slash. Obviously it accepts paths without > >>slashes, but if it should not accept them *with* slashes I'd need to > >>make the changed code aware of the OS. > >> > >>Could someone please test (or tell me directly) whether it makes a > >>difference if a path passed to -I has a trailing slash or not on > >>Mac? > >It's worth bearing in mind that AFAICT -I can take a relative path. > > Yes, it can. > Although it's not really relevant for my use case as Frescobaldi (at > least when used as intended) uses absolute paths. > > >In windows, D: and D:\ can be different directories depending on > >circumstances. No idea about the Mac, though. > > > >Is LP constructing filenames merely by concatenating part1, delimiter > >and part2? This usually works but isn't the Right Way, hence functions > >like Python's os.path.join(). > > I don't know what *LilyPond* does, but in Frescobaldi the path that > is stored by default is the result of a PyQt dialog's choice, so we > *can* expect it to be correct with regard to the actual OS. It's > just that this doesn't add a trailing slash to the path, and > LilyPond seems to choke on that on Windows. Then LP needs fixing. Sorry, but insisting that users specify directory names with a trailing (back)slash is plain wrong.¹ And, as shown above, mindlessly appending one is worse, as it can change the meaning of what the user wrote. Also, if someone writes -I D:foo and you want to convert it to an absolute path, it's necessary to find out what the current directory is on drive D: which may have no relationship to the current directory on the current drive (ie if D: is not the current drive). > (you can write *anything* in the line edit in Frescobaldi, so you > can also make it break, but I don't think we have to deal with wrong > input here.) AFAIK the rules for writing valid filenames and directory names in windows are well-defined and identical, ie the only way to distinguish a file from a directory by its name is to ask the OS. ¹Note that I'm not saying a user *can't* specify a trailing (back)slash on a directory name; the program can merely strip it (as long as it's not syntactically a root directory). Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
Am 15.08.2018 um 00:34 schrieb Hans Åberg: On 14 Aug 2018, at 21:31, Urs Liska wrote: Could someone please test (or tell me directly) whether it makes a difference if a path passed to -I has a trailing slash or not on Mac? It seems to not matter, tried on MacOS 10.13.6. That was what I expected. Thank you for testing Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
Am 14.08.2018 um 22:21 schrieb David Wright: On Tue 14 Aug 2018 at 21:31:18 (+0200), Urs Liska wrote: Hi all, it seems LilyPond on Windows requires paths passed to the -I command line option to have a trailing slash while LilyPond on Linux doesn't seem to care whether there is or not (see https://github.com/wbsoft/frescobaldi/issues/1094). It seems a fix to the issue in Frescobaldi is to ensure there's a trailing slash to the paths, which makes it work on Windows and Linux. Before merging this code I'd need to know whether Mac also doesn't care about the trailing slash. Obviously it accepts paths without slashes, but if it should not accept them *with* slashes I'd need to make the changed code aware of the OS. Could someone please test (or tell me directly) whether it makes a difference if a path passed to -I has a trailing slash or not on Mac? It's worth bearing in mind that AFAICT -I can take a relative path. Yes, it can. Although it's not really relevant for my use case as Frescobaldi (at least when used as intended) uses absolute paths. In windows, D: and D:\ can be different directories depending on circumstances. No idea about the Mac, though. Is LP constructing filenames merely by concatenating part1, delimiter and part2? This usually works but isn't the Right Way, hence functions like Python's os.path.join(). I don't know what *LilyPond* does, but in Frescobaldi the path that is stored by default is the result of a PyQt dialog's choice, so we *can* expect it to be correct with regard to the actual OS. It's just that this doesn't add a trailing slash to the path, and LilyPond seems to choke on that on Windows. (you can write *anything* in the line edit in Frescobaldi, so you can also make it break, but I don't think we have to deal with wrong input here.) Urs Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
> On 14 Aug 2018, at 21:31, Urs Liska wrote: > > Could someone please test (or tell me directly) whether it makes a difference > if a path passed to -I has a trailing slash or not on Mac? It seems to not matter, tried on MacOS 10.13.6. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Include path syntax on Mac
On Tue 14 Aug 2018 at 21:31:18 (+0200), Urs Liska wrote: > Hi all, > > it seems LilyPond on Windows requires paths passed to the -I command > line option to have a trailing slash while LilyPond on Linux doesn't > seem to care whether there is or not (see > https://github.com/wbsoft/frescobaldi/issues/1094). It seems a fix > to the issue in Frescobaldi is to ensure there's a trailing slash to > the paths, which makes it work on Windows and Linux. > > Before merging this code I'd need to know whether Mac also doesn't > care about the trailing slash. Obviously it accepts paths without > slashes, but if it should not accept them *with* slashes I'd need to > make the changed code aware of the OS. > > Could someone please test (or tell me directly) whether it makes a > difference if a path passed to -I has a trailing slash or not on > Mac? It's worth bearing in mind that AFAICT -I can take a relative path. In windows, D: and D:\ can be different directories depending on circumstances. No idea about the Mac, though. Is LP constructing filenames merely by concatenating part1, delimiter and part2? This usually works but isn't the Right Way, hence functions like Python's os.path.join(). Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \include path
On Tue, 2018-02-13 at 00:57 +0100, Urs Liska wrote: > Hi David, > > > Am 13.02.2018 um 00:33 schrieb David Sumbler: > > > > Is there a way of getting Lilypond to search for \include files in > > a particular directory, other than by using the command line option > > -I ? This is not very convenient, because I usually run Lllypond > > from Emacs, using Ctrl-C Ctrl-F. > > > > In bash I can add items to the environment variable PATH; perhaps > > there is something similar in Lilypond? > > > > The reason I ask is that, with the help of Stefano's very helpful > > "quick rundown", I thought I would experiment with the Edition > > Engraver. I am completely new to using 'git', but after some > > effort I managed to get the relevant parts of OpenLilyLib into a > > directory called ~/openlilylib/ . > > > > When I added \include "oll-core/package.ily" to my test.ly file, I > > got a "cannot find file" error, because Lilypond doesn't know where > > to look for it. If I give an absolute path or a relative path, > > package.ily loads OK, but then in that file the line '\include > > "oll-core/internal/os-path.ily"' produces an error for the same > > reason. > > > > Perhaps the answer is to put a symbolic link from somewhere in the > > lilypond code tree to the openlilylib directory, but then I would > > have to remember to recreate it every time I install a newer > > version of Lilypond, which again is less than convenient. > If Emacs doesn't have an option to construct a command line (like > Frescobaldi does) I would say the most straightforward way for you > would be to write a simple wrapper script that adds these command > line options for you and call that instead of 'lilypond'. Thanks very much for your help. I looked at lilypondmode.el, but I couldn't figure out how to modify the command that Emacs executes when I press Ctrl-C Ctrl-F. So following your other suggestion I wrote a script: #!/bin/sh exec /usr/local/bin/lilypond -I /home/david/openlilylib/ "$@" and saved it as ~/bin/lilypond . Works perfectly! David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \include path
Hi David, Am 13.02.2018 um 00:33 schrieb David Sumbler: Is there a way of getting Lilypond to search for \include files in a particular directory, other than by using the command line option -I ? This is not very convenient, because I usually run Lllypond from Emacs, using Ctrl-C Ctrl-F. In bash I can add items to the environment variable PATH; perhaps there is something similar in Lilypond? The reason I ask is that, with the help of Stefano's very helpful "quick rundown", I thought I would experiment with the Edition Engraver. I am completely new to using 'git', but after some effort I managed to get the relevant parts of OpenLilyLib into a directory called ~/openlilylib/ . When I added \include "oll-core/package.ily" to my test.ly file, I got a "cannot find file" error, because Lilypond doesn't know where to look for it. If I give an absolute path or a relative path, package.ily loads OK, but then in that file the line '\include "oll- core/internal/os-path.ily"' produces an error for the same reason. Perhaps the answer is to put a symbolic link from somewhere in the lilypond code tree to the openlilylib directory, but then I would have to remember to recreate it every time I install a newer version of Lilypond, which again is less than convenient. If Emacs doesn't have an option to construct a command line (like Frescobaldi does) I would say the most straightforward way for you would be to write a simple wrapper script that adds these command line options for you and call that instead of 'lilypond'. HTH Urs How can I get things to run smoothly? David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
