|
Viewing 1 to (11 Total) Latest Apple compiler |
Total Posts: 204
Joined: November 28, 2011
|
I have local changes to hxcpp and NME to use the latest Apple LLVM compiler (clang) for the iOS target. I initiated this update while out at WWDC as Apple has announced it will no longer be distributing or supporting gcc. I haven't yet finished the correlating change for OS X (darwin).
The biggest differences have to do with the fact that clang with Obj-C automatic reference counting (ARC) no longer requires retain/release calls or AutoReleasePool. I have been running this way since I was out at WWDC without any issues.
I want to stress this does not prevent compilation of legacy binaries to run on legacy iOS versions so this should be a non-breaking change. My feeling is this change should go into trunk ASAP.
When/if this goes into the SVN repositories the change to hxcpp will need to be coordinated with the changes to NME source because clang will not build anything that attempts to do its own memory management.
What do you guys think?
Patrick
Tags:
Posted on June 25, 2012 at 2:54 PM
|
|
|
Total Posts: 546
Joined: October 07, 2011
|
Re: Latest Apple compiler
Hi,
Can you put "#ifndef __CLANG__" or similar around the appropriate bit of code?
Apple can be very bad about allowing new compilers to be installed on old machines/OS, so ideally we would support both compilers as long as possible.
In hxcpp, I think we should find a smart what to choose clang vs gcc - probably based on if we can find clang, maybe on xcode version or something, and maybe with an environment variable to override for testing etc.
Hugh
Posted on June 25, 2012 at 11:29 PM
|
|
Total Posts: 204
Joined: November 28, 2011
|
Re: Latest Apple compiler
The only issue with that approach is we'd have lots and lots of those ifndefs. I don't have data in front of me with regard to how far back the LLVM compiler goes.
This sort of reopens the question of how far back we need to go for iOS support, since a fairly recent machine is needed to run the development tools for iOS 5/6.
I may just define iOS with LLVM and ARC as its own target separate from the current iphoneos target. As API's and things change it would be good to know there is a target that is kept up to date. One example of this is the UIViewController 'shouldAutorotateToInterfaceOrientation', which is now deprecated for iOS6.
Do you think a version of hxcpp/NME that is kept up to date but does not necessarily have the same level of backward compatibility a fork, or extension? The same should be available for Android.
I'd be interested in hearing from any developers with an opinion on this matter, I doubt I'm the only one looking for this.
Posted on June 27, 2012 at 8:46 AM
|
|
Total Posts: 546
Joined: October 07, 2011
|
Re: Latest Apple compiler
Hi,
A am loathed to maintain any kind of fork - it is just too much work. A few "#ifdef" or a "BEGIN_POOL" macros are much less work. At some point in the future, we can go though and remove the conditionals just to neaten up the code.
It is axiomatic that the absolute best thing for users of NME products is support as wide a range as possible, and use software to gracefully fallback when not possible.
It is then an engineering decision to remove support for older devices in order to make development easier.
So my preference to to try (reasonable hard) to find a "universal" solution. If this is not possible, drop support for the older device and let someone else maintain a port, if they really want.
On windows, you can use "getprocaddress" to check for compatibility. On android, you can use java reflection, linux expects you to have 10 year old boxen and it is just apple that flips the bird to backwards compatibility.
Can we use some kind of "target=ios4" flag to remove the deprecation warnings on shouldAutorotateToInterfaceOrientation?
And then use some kind of reflection to get at the advanced features? This would be the ideal solution.
Hugh
Posted on June 28, 2012 at 12:07 AM
|
Total Posts: 2140
Joined: August 25, 2011
|
Re: Latest Apple compiler
"...it is just apple that flips the bird to backwards compatibility"
This made my day 
Posted on June 29, 2012 at 2:48 AM
|
|
Total Posts: 204
Joined: November 28, 2011
|
Re: Latest Apple compiler
/me hopes haxenme.org does not devolve into totally needless debate...
I will be committing the changes to the NME side with the retain/release calls preserved using #ifndef OBJC_ARC.
In this way, folks will be able to decide just as with the HXCPP_ARMV7 switch whether or not they wish to use LLVM and Automatic Reference Counting in the NME build as well as in their own native extensions.
This does of course call into question what the default setting should be for the iOS ndll's that get distributed via haxelib. Because Apple is deprecating GCC I think clang and ARC should be the default (and because I believe it can be said objectively that clang is a better/faster compiler.. but I probably shouldn't say that because I have no interest in debate). ARC is enabled by default in Xcode and it will tend to be what developers will use for their own native extensions, so if we went with GCC by default, native extensions would not build.
Posted on June 29, 2012 at 11:41 AM
|
|
Total Posts: 2140
Joined: August 25, 2011
|
Re: Latest Apple compiler
Hi,
I am sorry if I sounded like I was trying to be divisive. Actually, I am in a position where I do not want to buy a new computer, but Apple has already made the (Apple) machine I have obsolete. Apple continues to break compatibility when developing with newer builds of Xcode, so there is some frustration there. Most of the places on the internet that I have seen having people saying that other operating systems are "just as bad" in terms of dropping support for older hardware, but that has not been my experience
So when you use clang instead of gcc, are the resulting binaries compatible with old versions of OS X and iOS?
Can we find out how long Apple has included a functional copy of clang with Xcode?
Thanks!
Posted on June 29, 2012 at 12:59 PM
|
|
Total Posts: 204
Joined: November 28, 2011
|
Re: Latest Apple compiler
the LLVM compiler has been in since xcode4. Even though LLVM can be used without ARC, I feel like for simplicity's sake they should go hand in hand. If people want/need to use GCC or opt not to use ARC they can do so with g++ compiler. If they want to use ARC or are using features only in iOS 5/6, the LLVM compiler is used.
I have the NMML "ios" tag set up with a "compiler" arg. If that arg is set to "llvm" ("clang" will also work), then the Xcode project and all the defines get configured for LLVM and ARC.
Since ARC is done in the compiler, there is no reason you could not target iOS 4 with it (and besides that, iOS 5 already has 70+% adoption anyway). I think it will soon become clear that we don't need this switch, but if it brings comfort in the interim, all the work has been done already anyway.
Patrick
Posted on June 29, 2012 at 1:19 PM
|
|
Total Posts: 204
Joined: November 28, 2011
|
Re: Latest Apple compiler
BTW - although these changes are now available in NME SVN, they will not be usable until the correlating changes to the iphoneos and iphonesim toolchains are committed to hxcpp. I'll let everyone know when that has happened.
Posted on June 29, 2012 at 1:37 PM
|
|
Total Posts: 546
Joined: October 07, 2011
|
Re: Latest Apple compiler
Hi,
I am more interesting in finding a pragmatic solution than starting a flame war - I'm just pointing out that I know of pragmatic solutions on all platforms except apple. I would really liked to be convinced that there is a pragmatic solution on apple too.
So can the libraries that are created (eg, nme.lib) can be linked against code from the haxe output (even if it is gcc?).
If it can be linked, then it should not really matter which compiler generates the lib - we should go with the smallest/fastest code version, since we will not be losing any developers who just "use" nme rather than "create" nme.
If not, and we have some developers who can only use llvm, and some who can only use gcc, then I think we need a new library suffix like the "-v7" as you suggest.
Hugh
Posted on July 02, 2012 at 1:17 AM
|
|
Total Posts: 204
Joined: November 28, 2011
|
Re: Latest Apple compiler
I *believe* it shouldn't matter what compiler is used to build the NDLL. I will always use LLVM because I appreciate its benefits (especially speed and extra warnings) and want to use libc++ for my own work. For now though, the GCC build NDLL should work just fine even if the end app is built with clang. The retain/release stuff is added by ARC at compile time so clang shouldn't be auditing the NDLL, just code it's told to compile in the app itself before linking.
So, it's more about what the user wishes to specify for the NME application they are building. If that's really the case, then the work is already done. It'll work once my local changes to hxcpp are committed. It's just a simple switch in the iOS toolchains to use clang and ARC when OBJC_ARC is set, and to use llvm-g++ when it is not.
Once GCC is no longer distributed with Xcode (this will happen sometime over the next year) I feel OBJC_ARC must be the default. For now to allow folks to ease into it and to reduce the element of surprise, it is unset by default so HXCPP will behave as it has even after my changes are committed.
Seem OK?
Patrick
Posted on July 03, 2012 at 11:21 AM
|
