On Mar 13, 2006, at 1:42 PM, Garth Hjelte wrote:
The weird thing I'm seeing is:
I have a Shared Bundle project in Codewarrior that I use for
something totally different (non-RB), it's Mach-O type of target.
Accesses the IOKit.framework, no problem.
I'm moving over part of that code to one of the example plugin RB
projects (I'm pretty new to plugins). I'm using the pluginCarbon
target. The .cpp I use for all this includes the IOKit framework,
and I put that path in the System Paths of the CW target (relative
paths, it's /System/Library/Frameworks/IOKit.framework). However, I
get an error that says it can't open IOKit.h.
If it's part of the example plugins, it is a PEF plugin, and
therefore you can't just call into Mach-O. You have to go through
something that will load it dynamically, so that it will insert the
glue code for you.
Now I assume (based on your answer) that it's because the framework
is in a bundle (I do see that all these things are in a Unix
executable file) and I need to access the bundle via the CFBUndle
commands. Now this seems like too much work, or is it?
Frameworks are a special type of bundle. CFBundle allows you to
dynamically load code at runtime. One benefit is that it allows Mach-
O to call PEF and PEF to call Mach-O. There is no way to "hard" link
a Mach-O framework from a PEF library.
I do see that a lot of those files in the framework exist on their
own in separate files inside the IOKit.framework folder. However,
when I try linking to those, I start getting all types of conflicts
within those. And it really doesn't seem like those files really
are self-sustaining.
To avoid this, should I make a Mach-O RB plugin? And to do that, I
must drop CW (which I will do soon enough, just not now) and use
XCode?
You don't have to drop CodeWarrior, but Xcode is much easier to use
to create a Mach-O plugin, IMHO.
No idea. I haven't ever seen that before.
OK, let me log things and perhaps something is hanging it. You
don't suppose it's that bridge, do you?
No, I don't. The amount of time the bridge takes to execute is on the
order of 6 instructions per call, which is very "cheap." The startup
time is affected a bit more, but I've never seen it take a noticeable
amount of time. For example, if you drop a BevelButton on a window,
and run that program as Mach-O, it will be using that bridge, and it
makes no perceivable difference at launch time.
HTH,
Jon
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
