Build System Management

From WxWiki
Jump to: navigation, search

Build System Management

The text of this page is taken from an email that David Elliott sent to wx-users on March 27, 2003. In it, "foobar" is used as the name of the program, called "fb" for short.

>Can (or should) I use the standard " su make install" "ldconfig"
>to install and link to either version of the lib as I wish?

Glad you asked!

I personally prefer to build with --prefix=/path/to/INSTALL_XYZ. Note that you can actually drop the d or r suffix since the library names and support files do not conflict between debug and release versions with the exception of wx-config which is a symlink to the last version (debug or release) that you installed. You can skirt that issue by explicitly specifying which wx-config you want for your program's build system which presumably you'll have to do anyway since wx-config will not be on your PATH (not necessarily a bad thing).

If you use an alternate prefix with --enable-shared (the default) then you must add /path/to/INSTALL_XYZ/lib to /etc/ before running ldconfig as usual. Alternatively, you can simply export LD_LIBRARY_PATH=/path/to/INSTALL_XYZ/lib before running your program which avoids the need to be root at all.

If you use an alternate prefix with --disable-shared (my preference) then you really don't have to do anything aside from providing the full path to the wx-config of your choice to your build system.

One advantage of this method: rm -rf /path/to/INSTALL_XYZ

That's probably all the information you need to know, but I'd also like to provide you with some concrete examples.

Let's say I'm compiling on my Mac OS X machine where I can (of course) build wxMac. I can also build wxGTK (since I have installed Apple's X11 and GTK from Fink). Even better, I can build wxMSW (since I build myself a cross compiler-- it's easier than you think). I could just as easily do all of this (except the Mac version) from a Linux machine (and did prior to using the Mac as my primary platform).

I could have a /Users/dfe/devel/wxHEADcvs directory containing the following paths.

wxWidgets (the source itself, checked out from CVS in this case, but it could be from a tar ball)

I also have under ~/devel the following similar directories: wxHEADcommit (CVS tree logged in as myself for commits), wx24cvs (the 2.4 branch from CVS), wx22cvs (the 2.2 branch which I had been using for my commercial program). In addition to using this system for wxWidgets I also use it for my own program. I keep my code in CVS (it's pretty simple to setup a repository on the local system) because otherwise I'd never be able to keep track of what I'm doing! So I have a fbHEADcvs, fbHEADcommit, fb20cvs, fb21cvs and so on all with a similar structure as follows:

... etc ...
foobar (the source dir, checked out from CVS in this case).

I personally find this to be a very sane, simple, and logical manner of keeping all of the code straight. YMMV.

To build wxWidgets I do the following:

cd ~/devel/wx24cvs/BUILD_GTKr
../wxWidgets/configure --prefix=/Users/dfe/devel/wx24cvs/INSTALL_GTK
make -j2 (dual CPU)
make install (no need to be root)

Then, to build my program (which uses autoconf with the wxwin.m4):

cd ~/devel/fb21cvs/BUILD_wx24GTKr
make -j2

Then to release:

make install-strip

That drops a stripped (debug symbols removed) bin/foobar under the



The GNU build system is certainly a powerful tool, and I highly recommend its use. The only thing I would like to have that I don't is the ability to readily compile with CodeWarrior or MSVC without making the project file by hand. To solve that I'd have to ditch automake in favor of something like tmake as wxWidgets itself uses. I'd still use autoconf for UNIX builds, but using tmake would make it easier to keep IDE project files up to date.


Hope that helps, -Dave