• 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: command line building - I'm pissed at Apple [10.4]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: command line building - I'm pissed at Apple [10.4]


  • Subject: Re: command line building - I'm pissed at Apple [10.4]
  • From: Bryan Pietrzak <email@hidden>
  • Date: Wed, 4 May 2005 12:46:49 -0500


On May 4, 2005, at 11:29 AM, Dieter Oberkofler wrote:

i'm just finishing porting an application that natively runs under windows from OS 9 using codewarrior to the os x platform using xcode 1.5. i have just ordered a new power mac g5 (running tiger and xcode 2.0) and i'm starting to be a little afraid in reading that under os x an application only seems to run when build for a specific version of os x and that everything is sdk/framework dependent even when shipping the production version. as a newby to xcode i would very much be interested in the following basic questions:

1) should an application build under xcode 1.5 not run on all version of os x (10.0 up to tiger)? if not, is this intended and are there workarounds?

If your projects in Xcode target an SDK, then generally speaking, yes it should run fine. There are always edge cases of course. The idea of SDKs is that they provide a consistent environment to target regardless of which environment you're actually running on.


Of course, the idea of targeting 10.0 is a bit odd -- no one in this particular universe is actually using 10.0.x anymore. Not unless they are a masochist. Hard to imagine that 98%+ Mac OS X users aren't on 10.2. or later.


2) to be portable between different operating systems, my application uses several 3rd party libraries from oracle, providence software and other vendors that actually have certified their libraries (frameworks) for xcode 1.5. is xcode 2.0 intended to run with xcode 1.5 libraries as well or not ?

That's really a vendor issue more than anything Apple related. But generally, yes, libraries can certainly be compatible with 1.5 and 2.0. Keep in mind that one of the things Apple is doing (and is right to do so!) is massively improving the libraries and headers. To quote Chris Espinosa from another mailing list:



On May 2, 2005, at 4:07 PM, Chris Espinosa wrote:

For Tiger we made a major effort at standards conformance, which involved many, many changes to BSD-style headers. Some header files were eliminated entirely per the standard (e.g. ansi.h). A lot of these things happen in the Darwin/Open Source context, so they're driven by the gnu community. It's very important to us to keep up our open source obligations.

This is good thing, but it can certainly create challenges trying to have one set of sources or libraries universally target multiple OS versions. But the price of NOT doing anything is much worse in my opinion.


3) how can i ship my application (bundle application) in a way that contains all the needed libraries (frameworks) and/or install them automaticall

You shouldn't install anything in /System or /Library or anyplace else really. Simply target an SDK and you should be. Static libs won't be an issue. Third party dynamic libs and frameworks can always be included inside your bundle.



Bryan _______________________________________________ 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
References: 
 >Re: command line building - I'm pissed at Apple [10.4] (From: Dieter Oberkofler <email@hidden>)

  • Prev by Date: Re: Xcode 2 Question
  • Next by Date: Predictive Compiling and Java
  • Previous by thread: Re: command line building - I'm ... at Apple [10.4]
  • Next by thread: compile issue with gcc 3.3 on tiger
  • Index(es):
    • Date
    • Thread