mark at livecode.com
Thu May 18 19:57:27 CEST 2017
On 2017-05-18 18:18, Mark Wieder via use-livecode wrote:
> That's unfortunate. It means that, aside from distributing the widget
> source code, compiled widgets are bound to a specific LC version with
> no guarantee that they will work with any other past or future
> version. Does 'major version' here mean 9.x or 9.0.x? Can I assume
> that the binary format will stay the same across all LC9.x releases?
I'm not sure it as much of a problem as it first appears to be - because
much the same is true of LiveCode Script.
If you write a script in 9 which uses features of 9, it will not work in
any version less than 9.
If you write a script in 8 then yes, we work very hard to ensure that
scripts will work exactly the same in 9.
So LiveCode Script is source forward-compatible (because we work had to
make it so); but not source backward-compatible.
Now, much the same is true of LiveCode Builder in terms of
source-compatibility (any source-compatibility issues should be reported
so we can look into it). However, currently, LiveCode Builder compiles
to a bytecode format which we do not guarantee inter-major version
compatibility of currently (whether 'major version' here is the first
version point, or first two version points is immaterial - we do
guarantee binary compatibility between maintenance releases).
However, 8.1.x module format is fixed and will not change, as is
lc-compile and the lcb standard library. This means that those specific
builds of tools will now and forever produce modules which load into
8.1.x - so we have a LCB8.1 toolchain.
Similarly, when 9 goes GM, the module format, lcb standard library and
lc-compile will forever produce modules which load into 9.0.x - so we
have an LCB9.0 toolchain.
If there comes a point where we do perhaps need to break
source-compatibility, we will make lc-compile more clever - making sure
it can be passed a 'source version' argument. Or we will reconsider the
module format slightly, raising its abstraction level slightly so this
isn't an issue, write a suitable converter and happily move on.
The point is the whole problem can be sufficiently solved quite well
with better tooling (which we are aware we need to work on); and in the
future can be solved completely using a little bit of cleverness and
exploiting the way LCB has been implemented.
> I have to say I'm surprised that we're still at this state of things
> so far after the fanfare introduction of extensions.
It is important to remember that LCB has only been in development (on
and off) for about 2 1/2 years at this point. Rust has taken over 7 to
get to source-compatibiliy stage (IIRC), and Swift broke source
compatibility at least twice I think since its launch - so I don't think
we are doing too badly (particularly when you compare the size of
Mozilla, Apple and us... I'll leave you guys to do the math there).
And on a slightly tongue-in-cheek note: I'm surprised after 26 years,
the linux world has not solved its binary compatibility problem. Indeed,
they don't seem to care about it one bit - even though it causes huge
amounts of wasted effort for any organisation daring to consider
distributing *binary only* applications. God forbid! (Also, the further
you move away from glibc in the Linux stack, the worse things get in
terms of source compatibility too...) ;)
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the use-livecode