wxHatch Reference
Advanced use of configure - integration between wxWidgets and wxHatch and your own projects

In the Building wxHatch pages, simple instructions for using
configure were provided. From version 1.35, wxHatch has the ability to interact with configure in more complex ways.
  1. In particular, wxhatch is no longer restricted to requiring wxWidgets configure to have been run in the root of the wxWidgets tree. This allows multiple builds of wxWidgets to share the same sources. wxWidgets is often built in subtrees or even outside the wxWidgets tree.
  2. wxHatch will create subfolders of the wxWidgets root dir, and you can use its GUI to configure and make wxWidgets in this subfolder
  3. For your projects, wxHatch will also generate redistributable configure.in , configure and Makefile.in , details are below
Building wxWidgets in subdirectories from the commandline

For example, suppose wxWidgets sources are in
~/wx , so that wxWidgets' configure is in ~wx/wxWidgets . Then, to build both debug and release builds  of wxWidgets you can do
cd ~wx/wxWidgets
mkdir mydebug
cd mydebug
../configure --enable-debug
cd contrib/src/stc
cd ~wx/wxWidgets
mkdir myrelease
cd myrelease


cd contrib/src/stc

If wxHatch is also extracted into
You can then build debug and release versions of wxHatch by doing
cd ~/wx/wxhatch
./configure --with-wxWINDIR=../wxWidgets/mydebug
cd ~/wx/wxhatch
./configure --with-wxWINDIR=../wxWidgets/myrelease

When running wxHatch, you can build debug and release versions of your own projects by using Choose |  wxWidgets Directory and switching between
wxWidgets/mydebug and wxWidgets/myrelease .

You can also create further wxWidgets configurations by using Choose | Select wxWidgets directory, creating a new directory and then using Make | Configure wxWidgets and Make | ReBuild wxWidgets Library

Out of tree builds

You can also build wxWidgets outside the  wx wxwidgets tree,  and wxHatch then needs a second parameter,
--with-wxWINMAINDIR which gives the path to wxWidgets main (top) directory. For example,

mkdir ~/wx/myunicode
cd ~/wx/myunicode
../wxWidgets/configure --enable-unicode
cd contrib/src/stc
cd ~wx/wxhatch
./configure --with-wxWINDIR=../wx/myunicode --with-wxWINMAINDIR=../wxWidgets

You can use wxhatch to generate configure.in and Makefile.in for your own out of tree projects which can tten be used by those without wxHatch  like this:
./configure --with-wxWINDIR=../wx/myunicode --with-wxWINMAINDIR=../wxWidgets

Configure in Your own projects

When you select compiler chosen by configure in the compiler choice dialog, wxHatch will create two files,
configure.in and Makefile.in . If you don't have autoconf on your platform, you can distribute these files to users, who can use autoconf and a unix toolchain to compile your projects. If autoconf is found on your system's path, then autoconf will be run and the configure file generated and run. The configure  shell script can be distributed with your project - this will allow users with development tools to run configure and make to build the project on their machine.

The configure script will follow the wxhatch syntax, expecting two paramters
--with-wxWINDIR and  --with-wxWINMAINDIR . These enable the script to locate the wxwidgets headers and libraries.

Makefile.in contains hardcoded version information, which your users may need to edit if the version of wxWidgets your users have does not match your version.


Sometimes you may get output like this:
Compiler output from project XXXXX saved at 2005-12-12 09:31:39
Starting job C:\wx\msys\1.0\bin\sh.exe -c 'autoconf'

Can't locate object method "path" via package "Autom4te::Request" (perhaps you forgot to load "Autom4te::Request"?) at /usr/bin/autom4te line 81.
Ended job C:\wx\msys\1.0\bin\sh.exe -c 'autoconf'

This is due to changing autoconf versions; fix it by deleteing the directory

wxHatch Home link to wxhatch help index