Mac OSX 10.5.4 build wxWedgets2.8.9 + xcode3.0 IDE

 Mac OSX 10.5.4 wxWedgets2.8.9 + xcode3.0

 

下载:wxWedgets-2.8.9 源代码

 

在终端使用root登录

$mkdir /path

$chmod -R 755 /path

$cp <wxWidgets> /path

$chmod -R 755 /path/wxWidgets-2.8.9/

$mkdir /path/wxWidgets-2.8.9/mac-build

$cd  /path/wxWidgets-2.8.9/mac-build

$../configure --enable-shared --enable-monolithic --enable-unicode --enable-universal_binary --with-mac --with-opengl --with-png=builtin --with-jpeg=builtin --with-tiff=builtin --with-expat=builtin

 

$nice make

$sudo make install

 

//set configure environment.plist
defaults write ~/.MacOSX/environment WXWIN -string "/path/wxWidgets/wxMac-2.8.9"; plutil -convert xml1 ~/.MacOSX/environment.plist

 

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)

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".

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!

Note that this will work automatically only if you built wxWidgets using the Xcode project. If you built using gnu autotools, and wish to bundle wxWidgets inside the app bundle :

• Use static binaries if you can, they save you all that trouble.
• Otherwise, if you really need dynamic librairies, check otool (especially otool -L) and install_name_tool on the terminal
• http://macdylibbundler.sf.net does the same but more automatised

Compiling and Running the Demos

Now try to build the demos from the Terminal window:

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

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)

Note : These instructions were tested with Xcode 3 and wxWidgets 2.8.9.

• Start Xcode.
• Choose menu item File --> New Project --> Command Line utility --> Carbon C++ Application (or any Application template, which one doesn't matter very much) then click Next
• Name the project and place it wherever you wish, then create it.
• Remove all files the wizard created, leaving only main.cpp (and maybe the .pch one, unless you don't want to use pch. then you'll need to deactivate them too in target settings)

• Replace the contents of main.cpp with that of a wxWidgets sample. Some samples may require images or other resources; in order to quickly build a template you can use the following minimal code :

    
    
    
    
 
     
 
      
#include "wx/wx.h" 
 
      
 
      
class MyApp: public wxApp
 
      
{
 
      
        bool OnInit();
 
      
        
 
      
        wxFrame *frame;
 
      
public:
 
      
        
 
      
};
 
      
 
      
IMPLEMENT_APP(MyApp)
 
      
 
      
 
      
bool MyApp::OnInit()
 
      
{
 
      
    wxBoxSizer* sizer = new wxBoxSizer(wxHORIZONTAL);
 
      
    frame = new wxFrame((wxFrame *)NULL, -1,  wxT("Hello wxWidgets"), wxPoint(50,50), wxSize(800,600));
 
      
    
 
      
    
 
      
    frame->Show();
 
      
    return true;
 
      
}
 
     
 
    Highlight your target under the "Targets" group in the tree on the left column 

• Right-click on it and select Get info, then switch to the Build tab.
• In the combo boxes at the top, make sure the Configuration one is set to All so you don't have to do it twice for debug and release. In the second called Show you can select all settings which is the most useful.

• In the architectures subsection, edit setting architectures so it matches your wxWidgets build (most importantly, if your wxWidgets build is not universal, you will want to change this setting to not build universal binaries)
• In Linking, turn off ZeroLink
• In GCC Code Generation, uncheck Inline Methods Hidden, uncheck Symbols Hidden by Default
• In Packaging, fill in the product name.

• Now open a terminal window, execute one of these sets of commands :

# if you did make install (make sure you get the right wx-config, you may need to adjust PATH)
wx-config --cppflags
wx-config --libs
 
# if you left wxWidgets in-place
cd /path/to/wxWidgets/mac-build

./wx-config --cppflags
./wx-config --libs

then copy the output of the two last commands. A conveniant way is to store them as envrionment variables to be called as $(VAR_NAME) from Xcode (see Setting Environment Variable For XCode for more info on this)

Warning : if you built wxWidgets as a universal binary, it will output flags like -arch ppc and -arch i386. Drop these flags because Xcode needs to manage Universal Binary stuff itself, passing flags to gcc without Xcode knowing will mix it up and result in linking errors.

• Under GCC Language, find Other C Flags, and in this field add the output of the wx-config --cppflags command.
• Under Linking, locate Other Linking Flags and there add the output of the wx-config --libs command.
• Close the settings window.

If you chose a wxWidgets sample more complex than the dummy code posted above, it may also be necessary to copy the sample.xpm file from wxMac-2.8.x/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.

• Time to compile! Cross your fingers that no error occurs.
• 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.

由于CodeBlocks8.02 在苹果上安装后，编译后的程序GUI界面不能响应，这个问题一直没解决，使用源代码安装太复杂，我尝试了几次也没能按装成功。不然使用CodeBlocks写wxwidgets跨平台的C++程序是一个不错的选择，功能强大。现在只能在Win平台写代码，然后copy到苹果平台，使用XCode编译链接成.App文件.这样也挺方便的。

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