[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Frescobaldi’s use of the version statement

From: Urs Liska
Subject: Re: Frescobaldi’s use of the version statement
Date: Sat, 10 Mar 2018 17:17:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Am 10.03.2018 um 17:12 schrieb David Wright:
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

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

Frescobaldi will (if that option is enabled) check the version statement in the file that is passed to LilyPond, i.e. the one that is "compiled". It will then choose that version or the next higher that is registered (which can be considered the closest match).

Whether all directly or implicitly included files match that version or are even compatible isn't the problem of Frescobaldi but that of the document author. (Actually I don't use the function and generally use the latest LilyPond version I have).

But I agree that in a situation like the current it wouldn't be a good idea to use that heuristics (but I don't think that's what Simon was actually suggesting anyway ...).



lilypond-user mailing list

reply via email to

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