Bakefile is cross-platform, cross-compiler native makefiles generator. It takes compiler-independent description of build tasks as input and generates native makefile (autoconf's Makefile.in, Visual C++ project, bcc makefile etc.).
This page describes its application to wxWidgets-based projects.
Official website: http://www.bakefile.org/
User extensions page: http://www.bakefile.org/wiki/UserExtensions
Because of all the different platforms wxWidgets has been made to work on, and due to all future platforms - there were a lot of makefiles and project files that had to be managed in order to support them. Whenever someone added a new source file, for instance, every makefile had to be hand-edited for the change. Bakefile came about to solve most of these problems.
Bakefile is a makefile autogenerator written in python; you give it some instructions (in form of an XML subset) and it will generate makefiles and project-files in many different formats (for the many different compilers existing) from scratch.
For more info please refer to http://www.bakefile.org.
To get started with Bakefile in your wxWidgets project you'll need to read carefully the wxWidgets' bakefile quickstart.
Another important reference is obviously the Bakefile documentation and in particular the Bakefile tutorial.
Update after you've done wx svn merge
As a wxWidgets developer, when you are done merging bakefile-related changes from trunk, if you see wired and unexpected @[email protected] strings in Makefile after configure, you should consider to "re-bake" your whole project. In case of wxGTK, this should fix it:
cd build/bakefiles bakefile_gen -f autoconf cd - autoconf -B build/autoconf_prepend-include
then re-run configure
OSX / Mac requires some special handling -
Never fear, though... I've been rummaging through the wx bakefiles and have come up with a tag of sorts to deal with this...
There are some problems though - you need to have the wxWidgets folder somewhere, because unfortunately it doesn't install some stuff you might need. By default in this tag its three directories below where the bakefiles are located (like how wxWidgets bakefiles are placed in wxWidgets/build/bakefiles).
You also need to know where your wx-installation is for the resource file - in here its hacked in at /usr/local but you could probably just -i /usr/local and -i /usr and be fairly safe.
Here's a tag for doing all the mac-stuff like generating resources for OSX with your bakefile. This has quite a bit from several wx bakefiles, with a little customization added:
<if cond="FORMAT=='gnu'"> <define-tag name="osx-bundle" rules="exe"> <set var="BUNDLE_IDENTIFIER">$(id)</set> <set var="WXDIR">../../../wxWidgets</set> <set var="MAC_VERSION">1.0</set> <set var="BUNDLE_PLIST">$(WXDIR)/src/mac/carbon/Info.plist.in</set> <set var="BUNDLE_RESOURCE">/usr/local/lib/libwx_mac-2.5.4.rsrc</set> <set var="BUNDLE_ICONS">$(WXDIR)/src/mac/carbon/wxmac.icns</set> <!-- bundle directory: --> <set var="BINDIR">../../bin/</set> <set var="BUNDLE">$(BINDIR)$(id).app/Contents</set> <set var="BUNDLE_TGT">$(BUNDLE)/PkgInfo</set> <set var="BUNDLE_TGT_REF">$(BUNDLE)/PkgInfo</set> <add-target target="$(BUNDLE_TGT)" type="action"/> <modify-target target="$(BUNDLE_TGT)"> <depends>$(id)</depends> <!-- required data: --> <command> /Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ -o $(BINDIR)$(id) Carbon.r /usr/local/lib/libwx_mac-2.5.4.r $(WXDIR)/samples/sample.r /Developer/Tools/SetFile -a C ../../bin/$(id) <!-- create the directories: --> mkdir -p $(BUNDLE) mkdir -p $(BUNDLE)/MacOS mkdir -p $(BUNDLE)/Resources <!-- Info.plist: --> sed -e "s/IDENTIFIER/$(BUNDLE_IDENTIFIER)/" \ -e "s/EXECUTABLE/$(id)/" \ -e "s/VERSION/$(MAC_VERSION)/" \ $(BUNDLE_PLIST) >$(BUNDLE)/Info.plist <!-- PkgInfo: --> echo -n "APPL????" >$(BUNDLE)/PkgInfo <!-- make a hardlink to the binary: --> ln -f $(ref("__targetdir",id))$(ref("__targetname",id)) $(BUNDLE)/MacOS/$(id) <!-- ditto wxWidgets resources and icons: --> cp -f $(BUNDLE_RESOURCE) $(BUNDLE)/Resources/$(id).rsrc cp -f $(BUNDLE_ICONS) $(BUNDLE)/Resources/wxmac.icns </command> </modify-target> <!-- add pseudo target id_bundle: --> <add-target target="$(id)_bundle" type="phony"/> <modify-target target="$(id)_bundle"> <dependency-of>all</dependency-of> <depends>$(BUNDLE_TGT_REF)</depends> </modify-target> <!-- "make clean" should delete the bundle: --> <modify-target target="clean"> <command>rm -rf $(id).app</command> </modify-target> </define-tag> </if>
Using this tag is really simple, just do something like:
<exe id="wikiservergui" template="appbase" cond="BUILDGUIAPP=='1'"> <app-type>gui</app-type> <dirname>$(GUIAPPDIR)</dirname> <syntaxhighlights>$(GUIAPPSOURCES)</syntaxhighlights> <headers>$(GUIAPPHEADERS)</headers> <if cond="FORMAT=='gnu'"> <osx-bundle/> </if> </exe>
And let it do the magic for you...
Another problem this arises is that you probably don't want to do that stuff if you're generating unix makefiles also. What I currently do is duplicate the bakefiles directory and change the above to one that will build for windows, etc:
<if cond="FORMAT=='gnu' and 0"> <osx-bundle/> </if>
It's a bit of a runaround. One thing you might want to do to ease your suffering on OSX is make a simple shell script like:
#!/bin/sh cd build/bakefiles bakefile_gen # bakemac contains the one with the osx-bundle tag enabled cd ../bakemac bakefile_gen cd ../unix make -f mac.gcc