Excellent info, Mark - thanks! -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ____________________________________________________________________ ambassa...@fourthworld.com http://www.FourthWorld.com
Mark Waddingham wrote: > 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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
