Re: Garbage collection in XCode 2.1, and Cocoa
Re: Garbage collection in XCode 2.1, and Cocoa
- Subject: Re: Garbage collection in XCode 2.1, and Cocoa
- From: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Thu, 28 Jul 2005 17:15:04 -0400
- Thread-topic: Garbage collection in XCode 2.1, and Cocoa
>We first described garbage collection for Objective-C at WWDC 2004.
>Over its implementation we have learned a lot about what it takes to
>provide a complete solution, so we haven't rolled it out for developer
>use yet. As Scott said, the setting leaked into the public release
>from our internal testing, and we apologize. We're continuing to work
>on the feature and appreciate your feedback.
Scott said to put in a bug report, I'll do that ASAP (although you might want to write one up yourself, I might forget :) )
>> As a second suggestion, I saw how there are complaints that the XCode
>> GUI doesn't track the GCC options at times. I would suggest that
>> someone work on turning GCC into a framework, or a server, and add in
>> a new command like GCCoptionsAsPlist() which would return a plist
>> formatted string that lists what options that that particular version
>> of GCC has. That way, XCode can parse the options strings, and know
>> what it is able to send to the GCC server.
>
>Unfortunately due to the fact that GCC is Gnu open source and to
>layering issues (it's the compiler), Apple can't make GCC dependent on
>any Apple framework. So it doesn't look possible to make GCC
>automatically vend every compiler option in a form Xcode can use. Even
>if it did, it would hardly be useful: GCC implements literally hundreds
>of compiler switches, only a few dozen of which are generally useful
>enough to present in the Xcode UI (and even with our being very
>selective, people still complain about the vas sea of options).
I didn't mean for to make GCC dependent on frameworks, I meant that converting it INTO a framework (or a daemon server) might be a worthwhile option. In that way, instead of doing command line scraping, you have a series of well known headers that you link against, or you have a server that you communicate with using some standard messages.
My idea for the plists was that plists are just XML files. If the call returns a pointer to a string that is just a bunch of XML, then any XML parser can read it. GCC would then be able to easily advertise what services it had been compiled with and was prepared to offer; E.g.
IDE -- message to GCC asking about services --> GCC daemon
IDE <-- XML plist specfying options -- GCC daemon
The IDE just needs to know that the options are boolean, integer, etc., what group they go with, and be able to display a human readable string that GCC supplies. The IDE could be a command line, a GUI, or anything else. Basically, the IDE is the View, and GCC is the Model in an MVC view of things.
>Our architecture is that for each tool there is a specification plist
>that has entries for each compiler switch, giving it a human-readable
>name, a short description, a build setting variable, a manner to
>display it in the inspector (check box, string, popup), and a default
>value. It's pretty easy, when we hear about a new compiler flag, to
>create this plist to keep them in sync; I added three or four for Intel
>support in a matter of minutes.
>
>This is also useful in that it scales to other compilers quite easily;
>IBM provides a similar spec for xlc, and Intel will do so for icc.
>Having 3rd party compilers export an API that returns an Apple-only
>plist is unreasonable.
OK, NOW I see the argument against modifying GCC in this manner; I didn't know you were supporting all the other compilers that are coming out as well, I thought GCC was all that you were working on.
Thanks,
Cem Karan
<<winmail.dat>>
_______________________________________________
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