James,
I think it is great you have managed to spur some feedback on this topic. I've
been awaiting some actual working debug-capable steps for XCode. Though I
cannot seem to reproduce your solution... I don't have the setup for
automatically bundling the dylib to .rbx, but I did that by hand with the sdk's
plugin converter. XCode fires up RB IDE, but does not break anywhere in my
plugin when the program is executed. I had two questions: 1) I assume we set
RB to 'OS X Carbon Mach-O' versus the PEF option or does it matter?, and 2) not
sure why/how it works being set to the IDE when all past discussion (i.e. CW
debugging) has centered around pointing at a built RB project? Can you clarify
these points?
> ----------
> From: realbasic-plugins-bounces at lists dot realsoftware dot com on
> behalf of James Milne
> Reply To: REALbasic Plugins
> Sent: Sunday, November 21, 2004 7:41 PM
> To: REALbasic Plugins
> Subject: Developing plugins with Xcode
>
> Hi guys,
>
> Just thought I'd share some of my experiences developing plugins with
> Xcode.
>
> I've recently moved most of my plugins across to Xcode. This has been
> made more practical with the release of REALbasic 5.5.4, which allows
> you to load plugins from Mach-O format without having to include a CFM
> stub.
>
> I did this for a couple of reasons:
>
> a) It moves me away from the constant treadmill of upgrading
> Codewarrior, saving me money every 12 months
>
> b) It makes it easier to debug my plugins, since I've always had
> problems using Codewarrior's debugger on Mac OS X
>
> Now that I've got them moved over, I'm fairly happy. The one thing I
> have lost is the ability to compile my Win32 plugin targets from within
> the same IDE as my Mac ones. However, there are ways around that (which
> I will detail at a later date! :-)
>
> Apple have documentation which is helpful for moving Codewarrior
> projects over to Xcode. It is a decent starting point for someone who,
> like myself, has previously been developing plugins in Codewarrior.
>
> There will probably be a few stumbling blocks for people who try to
> move their plugins across to Xcode. Here are the ones I encountered,
> and how I addressed them. Hopefully this might help anyone else who is
> looking to move across to Xcode.
>
> 1) Precompiled headers
>
> I had some problems with the RB Plugin SDK being used in precompiled
> headers in Xcode. For the uninitiated, a precompiled header file is a
> file which #include's a number of headers you need for the whole of
> your project, and caches them into a form which makes it quicker to
> compile the other source files in your app.
>
> The RB Plugin SDK uses C++ namespaces to isolate QT movie types. This
> is an old constraint for dealing with Win32. However, Xcode balks at
> this at first, as it usually interprets precompiled header files as
> referencing C code.
>
> At first, I modified the RB Plugin SDK to remove the use of namespaces.
> However, this has transpired to be unnecessary.
>
> To combat this, you can set a preference for you target. Specifically,
> if you open the info window for your plugin target in Xcode, then click
> on the Build tab and select GNU C/C++ Compiler from the list, you can
> modify the Compile Sources As option. Set this to C++, and this should
> avoid this problem.
>
> 2) Bundling your plugin dylib so that REALbasic can load it
>
> To do this, I wrote a simple RB command-line project which takes the
> contents of a folder and builds it into a .rbx file (which is really
> just a REALbasic Virtual Volume.)
>
> You can integrate this tool into the Xcode build process by creating a
> Shell Script Build Phase.
>
> For a Shell Script Build Phase, you can write a bunch of shell commands
> which are executed after the main part of compiling your target has
> completed.
>
> In my Shell Script build phase, I copy the dylib file from the Xcode >
> build directory for my project, and put it into a folder hierarchy
> which is laid out as it should be inside the virtual volume. I then get
> the shell script to execute my command line RB plugin assembler app.
>
> The assembler app produces the .rbx file. Out of convenience, for my
> 'Development' build style, I get it to copy the .rbx file straight into
> the REALbasic plugins directory.
>
> 3) Debugging your plugin
>
> At first glance, there is no obvious way to set up Xcode to debug your
> plugin.
>
> To debug your plugin, you first need to add an Executable to your
> project. You don't want to add REALbasic itself as the executable.
> REALbasic is a CFM application, and as such will not be recognised by
> Xcode's debugger as a valid host executable for your plugin.
>
> Instead, you need to add a support application called LaunchCFMApp to
> your project as the executable. The path to LaunchCFMApp is:
>
> /System/Library/Frameworks/Carbon.framework/Versions/A/Support/
> LaunchCFMApp
>
> As an argument to LaunchCFMApp, you want to pass the path to REALbasic,
> which on my machine is:
>
> /Volumes/Development/Applications/REALbasic/REALbasic\ 5.5.4\
> X.app/Contents/MacOS/REALbasic\ 5.5.4\ Mac\ OS\ X
>
> With this executable added to your project, the Run Executable and
> Debug Executable options in the Debug menu will be enabled. This will
> fire up REALbasic, and you will be able to debug your plugin with
> breakpoints, etc.
>
> --
> Kind Regards,
> James Milne
>
> p.s. I'll find my frog
>
> _______________________________________________
> 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>
>
>
>
_______________________________________________
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>
|