Again, let me say that your presence on this list is greatly appreciated. This kind of look behind the scenes at what you are doing and the problems you are tackling is enormously helpful to all of us. In the absence of this kind of information it is easy to assume that our error reports and complaints are being ignored. Obviously they are not. Thank you for shepherding the growth our favorite RAD environment.
-- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Apr 25, 2015, at 3:02 PM, 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 ~ m...@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 _______________________________________________ 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
