Compiling wxWidgets using the command-line (Terminal)

From WxWiki
Revision as of 08:16, 18 November 2021 by LN (talk | contribs) (→‎Make: It's surely safe to recommend make with 3 concurrent jobs today.)
Jump to navigation Jump to search
This article applies to the following versions
Platform wxWidgets Xcode
Mac OS X 10.5/10.6 2.8.x

2.9.x

3.1 or newer
Status: Up to Date

Install Xcode

In order to compile under OS X using the command-line, you will need to install Xcode, which will also install the gcc compiler, make programs,etc. Please follow the steps described in Installing Xcode.

Download and Install wxWidgets

See Downloading and installing wxWidgets.


Building the library

Open the terminal, which can be found under Applications/Utilities/Terminal

Change directory to the WX root

For example:

cd /Volumes/dev/wx/wx289

hint: after typing 'cd ', you can auto-fill the path by dragging the wx root folder from Finder to the Terminal window.

SVN users

If you got the SVN version of wxWidgets, you will want to run the following command at this point (if you use a source archive you can skip this step) :

./autogen.sh

Mac OS X 10.4 and earlier users may need to update their autotools first.

Create an output directory for the 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' (see Understanding wxWidgets Build Scheme for more info). Pick a naming convention you would like to use for these subdirectories. One common convention is 'build-release' and 'build-debug'. So for example:

mkdir build-release

Make sure to change to this newly created directory:

cd build-release

You can create multiple build directories if you wish to create multiple wxWidgets builds with different configurations.

Configure the library

You will now configure the wxWidgets code for a specific type of build, for example, the following will produce a static library with Unicode support:

../configure --disable-shared --enable-unicode --prefix="$(pwd)"

Note: While using a static library simplifies distributing your binaries to others, static linking may be severely slower than dynamic linking, which is something to keep in mind during development.

For further details on possible configure flags, see Possible Configure Flags under OS X.

For wxWidgets 2.8.x or older with Mac OS X 10.6 or newer, see Development:_wxMac

  • Mac OS X 10.7 Lion
    • Try something like this:
$ ../configure --with-osx_cocoa --with-macosx-version-min=10.7 --with-macosx-sdk=/Developer/SDKs/MacOSX10.7.sdk --prefix="$(pwd)"
  • Mac OS X 10.8 / XCode 4.4
    • Try something like this:
../configure --with-osx_cocoa --with-macosx-version-min=10.7 --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk --prefix="$(pwd)"

Make

Compile the wxWidgets code by executing:

make -j3

The entire build takes about 6 minutes on a quad 2.66 GHz Power Mac.

The build output

Following make, you will find the built library under your folder (eg, build-release). This is also where the corresponding wx-config is.

FAQ

What if I need to rebuild the library?

If you wish to rebuild the library (for example if you changed setup.h, or want to pass new flags to configure), it is recommended that you delete the entire build folder (eg, build-release) and start fresh with a new one. Otherwise it is likely you will have mismatched files in your build directory.

What is Make Install for?

Make Install puts your wxWidgets build in a system-wide directory. Running make install is not necessary nor recommended in most cases. Note that it may be necessary in dynamic builds if you do not set the --prefix as above, because dynamic libraries may not be found at runtime if they're in a local wx directory.

Note: OS X 10.6 ships with wxWidgets and a wx-config already resides in /usr/bin, when you run make install the lib will be installed by default to /usr/local/lib and the wx-config to /usr/local/bin. But OS X searches /usr/bin before it does /usr/local/bin (you can check where wx-config runs from using whereis wx-config). So if you do make install the right call to wx-config will be /usr/local/bin/wx-config.

Why shouldn't I run it?

The main reason why not run it is that if you build multiple builds of wxWidgets (eg, a dynamic debug one and a static release universal binary) it is easier for them to mix up each other when you install them to system-wide directories. A local wx-config will be generated anyway and you can use that local wx-config with no need to install wxWidgets to a system-wide directory.

Also, for applications you package and distribute, this is rarely relevant since you will be using a static build, thus wxWidgets will be bundled with your application.

Third reason is, when you have wxWidgets installed in a system-wide directory, you may not easily notice your distributable application dynamically links to a file that is not available on a clean Mac OS X installation.

Why should I run it?

The reason to do it would be :

  • you want the libs available to other users who don't have permissions to access the wxWidgets build dir

What is the --prefix sometimes given to configure?

Issuing --prefix to configure means that when you run Make Install your wxWidgets library will be installed to a location different from the default /usr/local/lib. It also affects dynamic library paths even when you do not install.

For example, if you wish the library to be installed to /opt/lib you would call:

../configure --disable-shared --enable-unicode --prefix=/opt

NB: Do not set prefix to /usr, installing on top of wx libraries supplied with Mac OS X could break things.

Samples

wxWidgets comes with many samples and demos. If it's your first time with wxWidgets, you might want to try them. Navigate to the demos and samples directories inside your build folder (not the ones at the root of the wx sources, those will contain the source code and generic build files only). They will contain makefiles generated specially for your platform.

See Also