Re: coremidi & codewarrior
Re: coremidi & codewarrior
- Subject: Re: coremidi & codewarrior
- From: Andrew Kimpton <email@hidden>
- Date: Mon, 11 Feb 2002 20:28:39 -0800
Laurent Cerveau wrote:
On Monday, February 11, 2002, at 01:06 PM, Mark Gilbert wrote:
This certainly helps.
For people like us who have quite a few OMS apps to port, the
established route has been to first carbonise them in CW 7.2.
Question is (sorry to be so ignorant about Mach-O), how hard is it
to port a Carbon app to Mach-O ?
Is this easier than work around calling frameworks from CFM ?
It should really be. The dev environment and the compiler should
mainly do that for you. Basically this imply moving your project to an
"OS X like" environment that is adding the right frameworks, putting
the right plist attributes, properly using headers for umbrella
frameworks . I know I really simplify, but in my experience, there
should not be any code change .
I'd echo that with a few caveats :
Building Mach-O versions of your apps is relatively straightforward
regardless of whether you engage the Codewarrior Mach-O tools or convert
to using ProjectBuilder - assuming your app is already Carbonized.
Switching to Framework style includes for your headers can make life a
lot easier
If you have any assembly language code that is being assembled by
Codewarrior you'll have to convert it to Gnu Assembler Syntax, build it
into a .o file using the command line gas tool and add the resultant .o
file to the project to be linked. For some reason it seems that the
Codewarrior assembler doesn't (yet ?) emit mach-o format object files.
Lastly - and this is a big one, especially in the Audio space. If you
use (host) plugins in your app, or if you are a plugin for some other
app then you'll still have to 'deal' with cross architecture calling
(use the tricks as mentioned elsewhere in this thread) possibly in an
even more complicated manner if the plugin API utilises a lot of
callback function pointers and the like. This particular problem is
perhaps the most thorny and still needs quite a bit of 'vendor' work.
It's one thing to publish Carbonized API's and SDKs, it's another to
deal with the binary format for all your VST plugins (for example). How
are they built ? CFM/PEF or Mach-o/dyld ? Do they use Bundle style
packaging ? And so forth - and that's before you worry about whether you
should really be switching to Audio Units 8-)
So in can be quick, but it can also lead to a lot more unanswered
questions !! For example I just added a target to my codewarrior project
for a large (a few hundred source files) app that will build a Mach-O
version of the target. The app was already largely carbonized with only
a few areas still to tackle (and bugs to fix 8-), adding the Mach-O
target took less than a day, but I haven't yet dealt with any of the
plugin issues.
Andrew 8-)
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.