Getting started on OS X

From WxWiki

Jump to: navigation, search

Contents

These instructions describe how to use wxWidgets 2.8.4 with Xcode for Mac OS X.

Other articles are available for older versions. You can also view older revisions of this article by clicking 'history' at the top.

  • Written by Tim Griesser, February 28, 2004 for wxWidgets 2.4.2
  • Updated by Tim Griesser, June 18, 2004 for wxWidgets 2.5.2 and CVS HEAD
  • Updated by Tim Griesser, December 8, 2004 for wxWidgets 2.5.3 and Xcode 1.5
  • Updated by Tim Griesser, June 16, 2005 for wxWidgets 2.6.1 and Xcode 2.0
  • Updated September 28, 2006 for wxWidgets 2.6.3 and Xcode 2.3
  • Minor Update by Geoff Ericksson, December 7, 2006 for MacPorts and Xcode Project Templates
  • Updated by Marianne Gagnon, June 24 2007, to clean up the mess and update to 2.8.4 (removed the quick and dirty duplicate instructions at top and merged them with the body of the article) Updated to SVN
  • Minor updates by Matt Browne, January 2, 2008 to note additional Xcode configuration options that may be needed in order to get the sample running.
  • Updated by Kip Warner, February 20, 2008 to note linker problems under Leopard.

[edit] Installing wxWidgets from Source

[edit] Mac and/or Programming Newbies

If you are new to the Macintosh, you'll probably want to buy a book or learn more about the system in order to not be lost.

It is recommended to have two accounts on your Macintosh computer, one being an admin account, then other a user account. Then you can do all of your work in your user account, and just use the admin account to install software such as Xcode (You will not need a superuser or root account in these instructions, as 'sudo' in admin account is sufficient).

Log-in to an admin account to install Xcode.

Xcode is included free with Mac OS X 10.3 or later and will not work with older systems.

Xcode is not preinstalled but it does come on the CDs or DVD included with any Macintosh, you just need to install it yourself. Alternatively, you can get the latest version of Xcode from Apple's website for a nominal shipping charge, or download it from there.

Xcode is typically installed into the /Developer directory. The documentation is then in this directory:

/Developer/ADC Reference Library/referencelibrary/index.html

You should add this page to your hotlist or bookmarks in your browser because you will refer to this documentation often. You can use this documentation for learning about Carbon, GCC, Xcode, etc.

In Finder, click on Applications, then click on Utilities. You will see the Terminal program. Drag Terminal to the Dock. You will be using Terminal often, so it is handy to have it on the Dock.

[edit] Getting the Source

Visit the wxWidgets Downloads Page, and download the wxMac source distribution.

You can from there download the latest stable version, and also the previous one. Unless you want to build an applciation that hasn't yet migrated to the latest one, you will want the latest version.

For the current development version with all latest changes but also possible unstability, you can get the code from SVN. Note that this is not for the average user as it is in development stuff - it may as well stop building some day, new and updated files appear in this branch daily.

You will also want to download the documentation, in PDF and HTML, from the same download page.

If you downloaded HTML documentation, you will have an archive, and you can unpack it and place it where you want to refer to it later. In the HTML archive, a good place to start is to open /wx/wx_contents.html.

For the PDF version, I recommend taking /Users/yourname/wx/ver/docs/pdf/wx.pdf (1984 pages) to your local copy shop for printing. Ask them to print this document double sided and then bind them into three books of roughly 330 sheets per book. It is great reference material and well worth the price of printing and binding.

If You Downloaded a Source Package:

Check for patches at http://www.wxwidgets.org/patch.htm

From Finder, double click on each the archives to unpack them. This will create a new directory: wxMac-2.8.4

You can now delete the archive (*.tar) and (*.tar.gz) files if you want. Or you can archive these files somewhere in case you want to reinstall the libraries later.

You can now move the wxMac-2.8.4 directory to a good working location. Any name will do, but you probably should leave 2.8.4 somewhere in the name because you may decide to use a newer version in the future. Notice that you will not be able to move this folder later without breaking the wxWidgets build.

If You Downloaded from SVN:

Make sure SVN is installed on your computer (http://metissian.com/projects/macosx/subversion/). Open a Terminal window by clicking on the Terminal icon in the Dock.

Check out the source code:

svn checkout http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/ wxWidgets-svn

You should now have a directory ~/wxWidgets-svn with all of the source code in it. New files appear in this branch daily. If you ever want to update the SVN files, do this:

cd wxWidgets-svn
svn update

You must now configure the makefiles. To do this from the terminal window, type:

cd wxWidgets-svn
autoconf

On Mac OS X version 10.3, you may receive an error message that autoconf needs to be updated. If you do, go to [www.gnu.org GNU] and get autoconf-2.59.tar.gz. You will need to login as an administrator to install this package. Once the package is installed, run autoconf like this instead:

cd wxWidgets-svn
/usr/local/bin/autoconf

[edit] Compiling wxWidgets from Xcode

Note: Compiling from the terminal (explained below) is better supported, and more reliable.

Open up the wxMac-2.8.4 folder, then open up the src folder. In that folder you will find a file called wxWindows.xcodeproj ( NOT just wxWindows.xcode ). Double click on it to launch it. In the Xcode Build menu, make sure "Allow zerolink" is UNchecked. (right-click target, select "Get Info", select "Linking" in section "Collection")

In the Xcode wxWindows window click on the Active Target button and select "Build All" Click on the Build icon. It will take some time. When it is completed Xcode will have generated lots of warnings but they aren't fatal so forget it and get over it. You can then close the project.

There's a couple of interesting things, which should probably be fixed / or you should be aware of:

  1. The library version says 2.8.3 (from 2.8.4 download)
  2. The dynamic library install directory is "@executable_path/../Frameworks" (see note below in install directory)
  3. This project creates it's output in "wxWidgets/src/build" which is ugly IMO.
  4. A single "wx/setup.h" file is created that is used for both debug and release builds. This is different to how the 'configure' method works below.
  5. There's also a distinct lack of a project template that will link against the output of this Xcode project. (I might get around to making one soon)

[edit] Samples and Xcode

Now, time to try samples. Note that not all samples have Xcode projects.

  1. Navigate to the ~/wxMac-2.8.4/samples/minimal folder. In there you will find a file called "minimal.xcodeproj" (NOT just minimal.xcode) double click on it to launch it.
  2. From the Xcode minimal window click on the Active Target dropdown menu and select "All Targets". Click on the build icon.
  3. Navigate to ~/wxMac-2.8.4/samples/minimal/build/Development. There you will find the two applications all your work has just produced: "minimal" and "minimalDynamic".

[edit] Dynamic Library Install Directory

In Mac OS X, the run time dynamic library loader wants to know exactly where all of the dylibs are. Most frameworks are installed in the system files, and to be safe Xcode normally builds against an OS SDK (eg 10.4u SDK) which is a known configuration of 10.4 systems that you're application can link to. (So you don't need to copy the libraries).

Mac OS X 10.4 ships with wxWidgets 2.5 pre-installed, for interest's sake.

Mac OS Applications are packages, which also makes it easy for you to copy the dylib into your app's package folder, and the linker will find it. With the Xcode project above (2.8.4), this layout will work:

myProgram.app/
myProgram.app/Contents
myProgram.app/Contents/MacOS
myProgram.app/Contents/MacOS/myProgram    <-- this is your executable
myProgram.app/Contents/Frameworks/wxmac.dylib    <-- this is the dynamic library output of the wxWindows Xcode project.
(other files suchs as Info.plist have been omitted from this list)

To achieve this in your program's Xcode project, add a build phase to "Copy Files" and copy to the Executable path, with a subpath of "../Frameworks". Then when you build your app, Xcode will copy the dylib into the app's package where the linker can find it. And your app is linking to a relative path, which is easily transportable!

[edit] Compiling wxWidgets from the Terminal

Depending on how you got the source code, it will be in a different folder at a different location, but the following instructions still apply. Just make that when cd is called, you adapt the path to match your configuration (tip: type cd then a space then drag and drop the folder onto terminal window and you're ready to press enter)

Open a Terminal window by clicking on the Terminal icon in the Dock.

In the Terminal window, you will now configure the wxWidgets code for a specific type of build. Each type of build should be in its own subdirectory separate from the source code. Examples of build types are "release", "debug", "unicode", "monolithic", etc.

Pick a naming convention you would like to use for these subdirectories. One common convention is "build-release" and "build-debug". Make one of these subdirectories and then use "configure" to set up the Makefiles.

[edit] Configure

cd /path/to/wxmac-2.8.4
mkdir build-release
cd build-release
../configure --disable-shared --enable-unicode --prefix=$(pwd)

You can pass different flags to configure to change your build

--enable-universal_binary
Gives you a universal binary running on ppc and i386 OS X variants.
--with-macosx-version-min
For specifing the minimal supported OS X version, eg. --with-macosx-version-min=10.4
--with-macosx-sdk
For specifing which SDK you want to build against, the maximum system whose API you want to benefit from, ie it can run on newer systems, but newer APIs would not be used, eg --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk
--with-opengl
Enables OpenGL support
--disable-shared
Builds static libraries
--enable-unicode
Builds wxWidgets with Unicode support
--enable-monolithic
Packages everything in a single file. (do not combine with static build)

For a list of all possible flags, run "../configure --help".

Hint: Linking your own applications against dynamic libraries is quicker than against static ones.

Warning: If you have installed lipng, libjpg, etc., wxWidgets will depend on them. If you installed any of these libraries and still want wxWidgets to be self-contained in order to ease distibution, pass the following flags:

  • --with-libjpeg=builtin
  • --with-libpng=builtin
  • --with-regex=builtin
  • --with-libtiff=builtin
  • --with-zlib=builtin
  • --with-expat=builtin

This takes about 70 seconds on a dual 1.8 GHz Power Mac.

Warning: If you want to change the settings of "configure", delete the entire build-release directory and start fresh with a new one. Otherwise it is likely you will have mismatched files in your build directory.

[edit] Mac OS X Leopard (10.5) Notes

On this system you might run into some nifty problems if you use the latest SDK, build from the command line, and want to run the resulting binary under 10.4 as well. So for the moment, please use --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk and specifiy a 10.3 (2.8 branch) or 10.4 (trunk) minimal system --with-macosx-version-min=10.4.

For the brave: remove iconv from configure and run this before running configure:

export LDFLAGS='-flat_namespace'

Some HIShape calls have been moved from one framework to another, therefore the usual two-level namespace handling of the linker stores a 10.5 location and cannot find the corresponding call when running unter 10.4, flattening the namespace is the current workaround.

[edit] make

In the same Terminal window, compile the wxWidgets code by typing:

make

The entire build takes about 14 minutes on a dual 1.8 GHz Power Mac.

If you have any compile problems with 2.8.4, check the troubleshooting tips below. If you have any compile problems with SVN, then check the troubleshooting tips below, but be aware that it is possible that someone else broke the build and you will have to ask for help for it to be fixed.

Since configure was given --prefix=$(pwd) above, no make install phase is required. When you call wx-config, use the full path.

[edit] Compiling and Running the Demos

Now try to build the demos from the Terminal window:

cd /path/to/wxWidgets/build-release/demos
cd life; make; cd ..
cd bombs; make; cd ..
cd forty; make; cd ..

If you have any compile problems, check the troubleshooting tips below.

Now try to run the demos from the Terminal window. Sometimes the demo might start underneath your Terminal window, so you need to move the Terminal window to find it. Also you'll need to exit the demo before you'll be able to use the Terminal window again.

Try the demo of the Game of Life:

cd life
./life

Warning: the Life demo seems to not run correctly on many macs. if it doesn't on yours, don't bother, just try another one or one of the samples.

  • Draw on the grid using the left button on your mouse
  • Click the black triangle
  • Explore the game
  • When finished, exit the demo

Try the demo of Bombs:

cd ..
cd bombs
./bombs
  • Click on the grid
  • Explore the game
  • When finished, exit the demo.

Try the demo of Forty Thieves:

cd ..
cd forty
./forty
  • Drag the cards
  • Explore the game
  • When finished, exit the demo.

You can also run the demos from Finder. For example, using Finder, go to /path/to/wxMac-2.8.4/build-release/demos/forty and click on the icon which shows three squares colored red, blue and yellow.

[edit] Compiling and Running the Samples

Now try to build some samples from the Terminal window.

This is a very good sample of many of the widgets which you can use. Be sure to stretch the window to see all of the widgets. All other samples can be built the same way.

cd /path/to/wxWidgets/build-release/samples/widgets
make

An icon will appear in the folder, you can double-click it.

This sample shows the use of a notebook with multiple pages. Use the menu to insert or delete notebook pages. Be sure to stretch the window to see all of the notebook pages.

cd /path/to/wxWidgets/build-release/samples/notebook
make

This sample shows how to layout many children in a parent window. Be sure to use the menu to choose other types of layouts.

cd /path/to/wxWidgets/build-release/samples/layout
make

Continue to look through /path/to/wxWidgets/samples until you find one that closely matches the program you'd like to write. You'll then use that sample with Xcode below.

[edit] Install wxWidgets with MacPorts

If you have MacPorts (formerly known as DarwinPorts) already installed on your machine then wxWidgets can be installed simply running the command

sudo port install wxWidgets

[edit] Building Xcode Projects for wxWidgets Applications

If everything has worked so far, and you've picked a sample that matches the kind of program you'd like to write, then you are ready to try Xcode. You can pick any sample you like, but these instructions will assume that you picked /path/to/wxWidgets/samples/notebook.

Make a new directory for your own work such as /Users/yourname/test/notebook and then copy all of the files from /path/to/wxWidgets/samples/notebook to that directory (except perhaps the makefiles, which are not of any use for what we are about to do). Be sure to leave the original /path/to/wxWidgets/samples/notebook folder unchanged so you can compare it to your test directory if your test directory is not working.

Note: Xcode tends to create Universal Binary targets by default. If your wx libs are not universal, modifiy the 'architecture' flags.

  • Start Xcode.
  • Click "File, New Project ..., Empty Project", and then "Next"
  • Set the Project Name to "notebook"
  • Set the Project Directory to "~/test/notebook/"
  • Click Finish
  • Click "Project, New Target..., Carbon Application", and then "Next"
  • Set the Target Name to "notebook"
  • Click Finish
  • Close the window which appears called "Target notebook Info"
  • Highlight "notebook" under "Targets" in the left Groups&Files column
  • Click "Project, Add to project... "
  • Choose "~/test/notebook/notebook.cpp"
  • Click "Add", "Add"
  • Highlight "notebook" under "Targets" in the left Groups&Files column
  • Click "Projects, Add to project..."
  • Choose "path/to/wxWidgets/build-release/lib/libwx_mac-2.8.a (If you did not build a monolithic lib, you will have more than one library to add - just add all the libraries found in this folder. you can simply select them all in finder and drag'n'drop them to your Xcode project)
  • Click "Add", "Add"

Note: If you did not build with --enable-monolithic mode, you will have many libs to add.

Open a terminal window and execute these commands:

cd /path/to/wxWidgets/build-release
./wx-config --cppflags

Note that wx-config has printed a long string with some parameters starting with -I and some parameters starting with -D. You will use the parameters in the steps below.


Warning : if you built wxWidgets as a universal binary, it will output flags like -arch ppc and -arch i386. Do NOT add these flags to the XCode project. Instead, use XCode's project settings to make your project universal too; if you pass -arch flags XCode will not know you are trying to build a universal app (it does not read flags you pass...) and therefore you will get link errors.


  • Double-click on "notebook" under "Targets" in the left Groups&Files column
  • A Target Info window will appear. Choose the "Build" tab.
  • Select the "GNU C/C++ Compiler 4.0/Language" collection
  • Set "Other C Flags" to the list of parameters from wx-config which started with -D. For example:
Other C Flags = -D__WXMAC__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA

(Note: Although these entries are not in alphabetical order, you can still type in their names to find them quickly.)

  • Still inside the Build tab, select the "General/Search Paths" collection
  • Set "Header Search Paths" to the list of parameters from wx-config which started with -I. Do not include the -I. For example:
Header Search Path = /Users/yourname/wx/ver/build-release/lib/wx/include/mac-ansi-release-static-2.8 /Users/yourname/wx/ver/include /Users/yourname/wx/ver/contrib/include 

When you start writing your own code, you will also add your own header file directories in "User Header Search Paths" as needed.

  • Now set these other parameters:
  • Still in the Build tab, select the "General/Linking" collection:
ZeroLink = unchecked
Other Linker Flags = -framework IOKit -framework Carbon -framework System -liconv

On an Intel Mac at least (if not all Macs at this point), it now also appears necessary to include the Cocoa and QuickTime frameworks, so that you would instead use:

-framework IOKit -framework Carbon -framework System -liconv -framework Cocoa -framework QuickTime

These should be enough for the notebook sample, but if you get linker errors then you may need more. You can find out which are missing by checking the results of "./wx-config --libs".

  • Select the "General/Packaging" collection
Product Name = notebook
  • Select the "GNU C/C++ Compiler 4.0/Code Generation" collection
Generate Debug Symbols = checked
Optimization Level = None

You can increase the optimization level later after you get experience with the debugger.

  • Select the "General/Deployment" collection
Produce Unstripped Product = checked

(This doesn't appear to be necessary in Xcode 2.3)

  • Close the settings window.

To get the samples to run, it may also be necessary to copy the sample.xpm file from wxMac-2.8.6/samples to the folder above your project folder (you will know if Xcode gives the error "../sample.xpm: No such file or directory"). This should not be necessary for your own projects.

  • From the menu, click "Build, Build and Go".
  • Wait for the compile to complete.
  • From the menu, click "Build, Build Results"
  • Verify there are no errors in the "Build Results" window.
  • Fix any errors you see. see reported errors
  • Repeat until the program works; if you have problems, you may also want to try a simpler example, such as the Hello World program in the tutorial.
  • Note that by default, Xcode will create a distributable application package for you, located at [your project folder]/build/Debug/
  • You can also read the troubleshooting notes below.

(You can also set an environment variable such as $(WXWIN) to be, for example, /wxWidgets/wx262; see Setting Environment Variable For XCode for more information)

[edit] Other Ways to Build with Xcode

The instructions above helped you to create a Carbon target.

Here are three other methods to use wxWidgets in a Xcode project

  1. Make a legacy target following these instructions. This is a very straightforward way to get up and running quickly in Xcode using a legacy Project Builder style target. However Apple claims legacy targets are not quite as good because they have somewhat longer build times and cannot be used with the ZeroLink and Fix&Continue features of Xcode.
  2. Convert a legacy target to a native target. First follow the steps in (1) for a legacy target. Then highlight the target. Then in the project menu choose "Upgrade Target to Native". You will get a second target which is native, while retaining your original target which was legacy.
  3. Use a makefile. If you really prefer makefiles, then you can still use Xcode as your editor and debugger. To do this, choose an External target and then select your makefile. Xcode will use your makefile during the build, but will use it's own editor and debugger during development. The disadvantage of this technique is that you'll need to manually modify your makefile whenever you want to add files to the project. Note that you don't need a makefile to allow you to build from the command line. You can use 'xcodebuild' for that purpose as described below.

[edit] Xcode Project Templates

Xcode project templates (most likely not up to date) are available for download here. Installation is achieved by the following instructions.

  • If the directory

~/Library/Application Support/Apple/Developer Tools/Project Templates/ does not exist then copy the Project Templates directory from this disk image to ~/Library/Application Support/Apple/Developer Tools/

  • Otherwise copy the subdirectory wxWidgets from this disk image to

~/Library/Application Support/Apple/Developer Tools/Project Templates/

  • When Xcode is next restarted the wxWidget Project Templates will be available at the bottom of the New Project Assistant.
  • You may need to adjust the project's build settings to match where you have wxWidgets installed. These templates are configured with Target specific build settings which override the overall project build settings - make sure you change the right ones! See the section above on running `wxconfig --cflags` and so on.

[edit] Troubleshooting Compile-Time Errors

If Xcode can't find a header *.h file, go back and check your 'Header Search Path' under the Build Settings window. Make sure the header file is in the wx subdirectory of a directory in the Header Search Path.

Sometimes you will have the Header Search Path in the wrong order and you will get the wrong version of setup.h. There are three versions of setup.h:

  • build-release/lib/wx/include/mac-ansi-release-static-2.8/wx/setup.h
  • contrib/include/wx/deprecated/setup.h
  • include/wx/setup.h

You should only be using the first one and never the other two, which is why the first path should be first in your Header Search Path. Just to be safe, you can delete the other two files.

Sometimes Xcode gives an error message at the end of the compile without providing you enough details. To see more details, click "Build, Detailed Build Results". Then find the small icon in the lower left which looks like a paragraph of text and has balloon help that says "Select this to show or hide the build transcript". Select that icon and than stretch the window to be taller so you can see the transcript. (Thanks to Adrian for this tip.)

Alternatively you can see the complete build details by building from the command line using xcodebuild. Here are the steps:

  • Exit Xcode.
  • Your project will be saved as notebook.Xcode for example.
  • Run Terminal
  • In Terminal, cd to your working directory
  • Type Xcodebuild -buildstyle Development
  • Use Finder to look in the build directory to run the executable.

The advantages of xcodebuild are:

  • You can see the complete build and any associated error messages.
  • You can automate the build of your program.

Sometimes your build settings are incorrect. Open two Terminal windows. In the first one, compile a working sample:

cd /path/to/wxWidgets/build-release/samples/notebook
make clean
make

In the second one, build with xcodebuild which uses your project settings:

cd ~/test/notebook
xcodebuild clean
xcodebuild -buildstyle Development

Compare the output of the two builds. Many things will appear different but actually there will be just one or two wrong settings. You'll have to be a detective to determine which settings are wrong.

Sometimes you are missing some header files. If the compiler complains about an error for a symbol, check that you #include a header file that defines the symbol. If the compiler can't find the header file, you'll need to add the path under "Header Search Path" in the build settings.

If you ever want to change the parameters to ./configure, you must always remove the prior build directory first. For example, you might change the parameters of ./configure to make a debug build of wxWidgets. Always rename or remove the prior build directory first, then run ./configure, and then 'make'. Otherwise you can get a mixture of old and new files in the directory which will confuse the compiler, confuse you, and lead to strange errors and warnings.

[edit] Troubleshooting Linker Errors

Make sure you don't enable monolithic build (--enable-monolithic) if you are generating a static library (--disable-shared). wxWidgets will probably build and install fine, until you try to link against the libraries with your code or one of the samples. You probably have monolithic and static enabled together (while they are mutually exclusive for some reason) if you see something like this:

Undefined symbols for architecture i386:
  "wxTopLevelWindowMac::DoCentre(int)", referenced from:
      vtable for MyFramein minimal_minimal.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
Undefined symbols for architecture ppc:
  "wxTopLevelWindowMac::DoCentre(int)", referenced from:
      vtable for MyFramein minimal_minimal.o
ld: symbol(s) not found for architecture ppc
collect2: ld returned 1 exit status

[edit] Troubleshooting Run-Time Errors

If you program compiles in debug mode but will not run, check for a Zero Link unknown object error. wxWidgets will not work if ZeroLink is enabled. You can switch it off in Project Info->Build->Linking

If your program crashes when compiled from Xcode, but does not crash when compiled from the "samples" makefile, then it means that your compiler settings in Xcode do not match the compiler settings you used when you compiled the wxWidgets library. You can verify the compiler settings using xcodebuild as described above under "Troubleshooting Compile-Time Errors".

  • To use the debugger, choose "Debug, Show Debugger".
  • Open a *.cpp file and click in the left column to set breakpoints.
  • Click "Build and Debug"
  • When you stop on a breakpoint, you can choose to "Step Over", "Step Into", "Step Out", "Continue", etc.
  • You can click "Debug, Expressions..." to examine variables.

If you want to debug beyond your code and into the wxWidgets code, you need to do three things:

  1. Build a debug version of the wxWidgets library.
  2. Add this debug library to your Xcode project.
  3. Add the __WXDEBUG__ compile flag to your project.

Here are the three steps in detail:

1. Go to a Terminal Window

cd /path/to/wxWidgets
mkdir build-debug
cd build-debug
../configure --enable-debug --disable-shared --enable-monolithic
make 

2. Go to Xcode

  • Choose "Build, Clean"
  • Make a list of the *.a frameworks in the project
  • Highlight each framework *.a file and press "delete"
  • Click "Projects, Add Frameworks..."
  • Add back the same frameworks with a "d" in the name for 'debug'.

3. In the left column of Xcode, click on "Targets, notebook"

  • Click on "Project, Get Info..."
  • Click on the "Build" tab.
  • Add this additional entry to "Other C Flags": -D__WXDEBUG__
  • Click "Build, Build and Debug"

[edit] Data Formatters

Data formatters allow you to cutomize how variables are displayed in Xcode.

Useful Xcode Data Formatters

[edit] Conclusion

The procedures and troubleshooting tips described here should get you started with Xcode so you can start writing your own software as soon as possible.

I'm impressed at how good wxWidgets looks on Mac OS X. Thanks to everyone who worked on the port to Mac OS X.

Thanks also to John Mehringer, Paul Heller, Fredrik Roubert,and Kemp Cease for adding corrections and suggestions to earlier versions of this document. Their valuable comments have been incorporated above.

Good Luck,

Tim Griesser

Personal tools