Does Version 7.0.4 work with Xcode 6.3.1?
Mark Waddingham
mark at livecode.com
Sat Apr 25 15:02:37 EDT 2015
On 2015-04-25 18:20, Richard Gaskin wrote:
> It seems that every time Apple updates Xcode it breaks LC, requiring
> the team to set aside other work and rush another build out for that
> one OS. Many of the 7.0.x/6.7.x builds seem to fall into that
> category, and those of us waiting for resolution on issues for other
> platforms find this as frustrating as I'm sure the team does.
It is somewhat frustrating at times - yes (particularly as Apple have
upped the pace of Xcode and iOS updates recently).
> Working with Android is smooth as silk by comparison, rarely requiring
> any updates at all.
Android is a slightly different beast than iOS - partly because Google
has done very well to make every Android release a superset of the
previous one and thus older APIs and methods continue to work fine as
the platform evolves; and partly because there isn't an issue with
dynamic linking.
> What is it that makes the relationship between LC and Xcode so brittle
> that it requires revision with every Xcode update?
There are three factors here - technical, legal and resource.
The technical issue is that iOS apps must present themselves as a single
statically compiled executable - you are not allowed to load non-system
dynamic libraries at runtime. As LiveCode supports native code
externals, these cannot be done as dynamic libraries as they can be on
all the other platforms.
Instead, we have to 'mostly-link' the engine, and 'mostly-link' each
external. The Standalone Builder performs the final link step - and this
step requires the full iOS SDK to be installed (hence the dependence on
Xcode). Moreover, because all the mostly-linked pieces have been
'mostly-linked' against a specific iOS SDK, the Standalone Builder needs
access to the iOS SDK with which they were 'mostly-linked' in order to
be able to build the final fully-linked executable.
So, if you have 6.7.4 which contains products built using the iOS 8.2
SDK, you cannot use Xcode 6.3 to build a standalone because Xcode 6.3
does not contain the iOS 8.2 SDK which LiveCode needs to perform the
build.
The legal issue is that (as far as I'm aware) you are not allowed to
distribute 'publicly' any derived works of a beta SDK - the terms of the
iOS SDK Agreement for Beta releases is more restrictive than that of the
non-Beta releases (basically, only paid-up members of the Apple
Development Programme for iOS are allowed to access and use it). This
causes a timing issue for us, as it is dubious as to whether we are
allowed to distribute builds of LiveCode which contain components which
are linked against a Beta iOS SDK (there may be a more optimistic
interpretation, but I always tend towards the severely conservative when
it comes to long, complex, software licensing agreements!).
The upshot of this is that it results in a bit of a race for us as soon
as Apple 'decide' to make their latest and greatest work public.
The third issue is that of resources. Right now doing a build for a
release of LiveCode takes a considerable amount of man power - this
means we can't be quite as agile with releases as we would like and have
to roll iOS SDK updates into the current maintenance cycle.
> Is there anything that can be done to anticipate and work around what
> appears to be a disregard for backward compatibility in Xcode?
In terms of improving the current state of affairs then...
On the technical side of things there are options open to us in terms of
avoiding a direct dependence on the iOS SDK at the Standalone Builder
step (if we had enough engineering resources to pour into such a
project, that is). However, any technical solution along these lines
opens us up to legal issues (particularly with the Google vs Oracle
debacle still apparently 'not quite resolved', and restrictions imposed
with regard 'reverse engineering', 'fair-use' and the DMCA).
On the legal side of things, perhaps a more 'optimistic' reading of the
various SDK license agreements might help. However, as Ralph points out
- if you are worth multi-billions of dollars, you get to set the rules -
and I think it is wise for us to be conservative in this regard.
On the resource side of things then this is where we can and are doing
something :)
The biggest bottleneck we have right now to getting releases (whether
they be dp's, rc's or gm's) is the final build of the LiveCode
distribution. This is something we currently have (and have had for a
couple of months) people working on. We are currently in the process of
fully automating builds of LiveCode, with the ultimate aim of achieving
all-platform continuous integration.
When we have fully automated builds, it will free time from actually
preparing the final builds and will hopefully mean we can revise our
current process on iOS SDK updates and which releases to expect them in
(for example, it should mean that is possible for us to add a new iOS
SDK to the most recent stable versions of each branch we have as a gm-2,
rather than having to roll them into the next maintenance release).
Anyway, I hope this helps to explain the current situation, and also
what we are doing to improve it moving forward.
Warmest Regards,
Mark.
P.S. IANAL applies to any mention of 'interpretation' of the legal
documents mentioned above.
--
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the use-livecode
mailing list