don't set SO_REUSEADDR by default; added GSocket_SetReuseAddr()

[wxWidgets.git] / docs / cocoa / install.txt

wxCocoa is still a work in progress.

To compile it, you will need Apple's Developer Tools.  However, please
note that any work to make it suitable for GNUstep (which will require
a GCC release with Objective-C++) will be much appreciated.

For the time being, the standard configure/make method works.  You will
want to build static because there are a number of unimplemented functions
that a shared library will need (becuase of wxWidgets code internally using
them) but that a static library will not (because most of the samples
don't need it).

On my system I have the following:

Checked out CVS source is in:
/Users/dfe/devel/wxHEADcommit/wxWidgets
Debug build directory is:
/Users/dfe/devel/wxHEADcommit/BUILD_COCOAd

From the debug build directory:
$ ../wxWidgets/configure --with-cocoa --enable-debug --disable-shared
$ make
$ cd samples/minimal
$ make
$ ./minimal

You may also need to configure the library --without-expat.  It didn't
build last time I checked, but then again, several improvements have
been made since then.

For other samples, you will need to provide at the very least an empty
resource fork so the OS will recognize it as a GUI application.

From the debug build directory:
$ cd samples/drawing
$ make
$ true | /Developer/Tools/Rez -t APPL -o drawing
$ ./drawing

Note that the empty resource fork doesn't actually allow the app to be
started from the Finder (it thinks it's a classic app!) but does allow
it to run with a menubar and proper event handling from the command line.

I suspect (but am uncertain) that if we provided an empty plist resource
that the app would be recognized as a proper OS X application.  Obviously,
bundles would be preferrable, and any work on Bakefile (see
http://bakefile.sf.net/) would be much appreciated.  wxMac also needs
bundle building restored since the switch to Bakefile.