On Fri 09 Mar 2018 at 23:02:53 (+0100), Simon Albrecht wrote:
On 09.03.2018 17:13, David Wright wrote:
You can even use Frescobaldi's option "Automatically choose LilyPond version
>from document".
Ouch. I hadn't come across that one. Sounds really bad to me.
a) you're not really in control of what's running,
Huh? You can choose which of the LilyPond versions (that you have
installed) you make available to Frescobaldi. Then you start on a
project, and by typing the \version statement you also tell
Frescobaldi which LilyPond version to compile it with (assuming that
version is installed – fallback options are handled gracefully). In
the ‘terrible’ case that the version specified by the version
statement or the one chosen by Frescobaldi isn’t the one you wanted
to compile it with, you’d be able to see in the log panel.
I don’t see any problem with that.
When the problem under discussion appears to be one of versioning,
it doesn't seem a wise course of action to add one more method of
having version changes made under ones feet.
b) what happening when all the includes have different version numbers,
Frescobaldi will always go after the first one.
In the case cited, the problem started when the OP was running old
source files. If there were includes of, say, a user's collection
of .ily files, then one is inviting more wasted runs due to
"program too old" errors.
c) it sends a misleading message to a naive user that \version
statements are meant to*do* something, when that is not their function.
Just for interest, here are the version statements from the files
installed by lilypond-2.19.80-1.linux-64.sh
\version "2.14.0"
\version "2.16.0"
\version "2.17.25"
\version "2.17.6"
\version "2.18.2"
\version "2.19.16"
\version "2.19.22"
\version "2.19.25"
\version "2.19.29"
\version "2.19.46"
\version "2.19.80"
Development policy states that the \version statements will only be
updated when the file is actually changed. So all this means is that
some .ly file in the source code has been around without change
since 2.14.0, some were updated quite recently, etc.
Yes, I was aware of that. The point I was making was that any
collection of *ly files is likely to contain a variety of version
statements, and the one selected from a particular source file might
not be appropriate for all the files that get compiled in that run.