• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: iCode development tool
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: iCode development tool


  • Subject: Re: iCode development tool
  • From: Markus Hitter <email@hidden>
  • Date: Wed, 4 Jan 2006 11:20:43 +0100


Am 03.01.2006 um 22:41 schrieb Mark Munz (DevList):

On Jan 3, 2006, at 12:53 PM, Markus Hitter wrote:

Am 03.01.2006 um 19:54 schrieb Mark Munz (DevList):

Xcode is this hybrid-IDE trying to appease the command-line folks and trying to appease the GUI folks. Unfortunately, the GUI-side suffers as a result.

I don't see a necessary constraint here. Forking a task is almost as cheap as forking a thread.

Well, I wasn't just referring to performance. Instead, I was referring to UI design.

Using CLI tools in the background doesn't necessarily require manual editing of options, either.


But compare Xcode to Codewarrior and there is a HUGE performance difference, even now.

That's the drawback of gcc being an multi-platform multi-language compiler. Additionally, it's set in Xcode to compile two binaries by default. There isn't much one can do about it without loosing features (I'd love to loose features for gaining simplicity).


Integrating gcc more tightly into Xcode's GUI would immediately risk differences to a CLI invocation. A big can of worms Apple resisted to open for now.


That's not to say that the whole thing isn't run by command-line tools behind the scenes, but the user should never have to be exposed them.

When building a Cocoa app using frameworks, it is already this way. Integrating other pre-built code like autoconf-made libraries or static libraries is much less intuitive.


How about introducing "virtual" or "intelligent" frameworks? You could group headers and libraries spread over the file system to use them like frameworks after grouping. Seach paths pointing inside the framework would be included automatically. Static libraries would be stripped. Everything done one preferred way, people requesting personal tweaks would be pointed to use all-CLI. Manual editing of search paths could go away.


Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/




_______________________________________________ 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
  • Follow-Ups:
    • Re: iCode development tool
      • From: Jonathan del Strother <email@hidden>
References: 
 >Re: iCode development tool (From: Boyd Collier <email@hidden>)
 >Re: iCode development tool (From: Markus Hitter <email@hidden>)
 >Re: iCode development tool (From: Mark Munz (DevList) <email@hidden>)
 >Re: iCode development tool (From: Markus Hitter <email@hidden>)
 >Re: iCode development tool (From: "Mark Munz (DevList)" <email@hidden>)

  • Prev by Date: Re: iCode development tool
  • Next by Date: Re: iCode development tool
  • Previous by thread: Re: iCode development tool
  • Next by thread: Re: iCode development tool
  • Index(es):
    • Date
    • Thread