Re: Xcode compatibility with third party compilers
Re: Xcode compatibility with third party compilers
- Subject: Re: Xcode compatibility with third party compilers
- From: Jonas Maebe <email@hidden>
- Date: Sat, 5 Sep 2009 21:09:54 +0200
Hi Tim,
On 05 Sep 2009, at 17:51, Tim Triemstra wrote:
We can look at specific cases, of course, but there are very good
reasons why we want to turn on new compiler and linker features by
default. Many features we add improve performance, security, code
size, compatibility, etc - and we would want all new apps created
for our platforms to reap those features.
Getting thousands of apps using new features that improve
performance or security is exactly why these features are added.
Asking our (very many) developers to all manually turn on these new
features will dramatically hurt adoption, often of changes that
would make end users happier as a result.
I understand that, but I just wanted to point out that not doing so
also has upsides, and additionally is backwards compatible, unlike
this approach. I also want to note that these new features were not
documented or announced anywhere. In fact, the only mention of the
no_order_inits and no_order_data options that Google turns up anywhere
are my posts (and a bug report filed against our compiler).
Of course, even if we were to have "off by default" initially, at
some point they would need to be on by default. The platform needs
to evolve.
I fully agree there. Dead code stripping was indeed turned on by
default in Xcode 3.2, but this shouldn't have been a problem since the
bugs in that functionality that I reported have long been fixed.
Unfortunately, the default became "-dead_strip" rather than "-
no_dead_strip_inits_and_terms". I have no idea why that latter option
even needs to exist (it makes as much sense to me as "-
no_dead_strip_random_functions_you_use"), but as you might have
guessed by now: the libraries that we generate include init and term
routines and their purpose is not just to increase code size and
application initialisation time.
The reason that we did not automatically always specify "-
no_dead_strip_inits_and_terms" ourselves already, is that this option
has as side effect that dead code stripping itself also gets activated
(even if you don't specify -dead_strip), and dead code stripping was
buggy under 10.3/Xcode 1.5 (which we still support).
That being said, you bring up good points regarding visibility of
features, and detecting what the compiler or linker is doing.
Filing radars will help our team in these areas. Specific cases
like those you mention help tremendously.
I have filed specific radars against the problems that cropped up with
10.6 (just as I did for 10.5 and 10.4). I was however hoping more for
the ability to file some preventive radars so that the situation with
10.7 will be more enjoyable for us and our users.
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden