2. CppUnit, http://cppunit.sourceforge.net, a C++ unit testing framework. wxGuiTesting has been tested against version 1.12.0. Mandatory.
3. VTK, http://www.vtk.org, is a graphics toolkit which works on top of opengl. wxGuiTesting is capable of capturing and replaying events via vtk. Optional.
4. wxVTK, http://wxvtk.sourceforge.net, a wx control for VTK. There's an older version in the sources, but you may want to get the latest. Optional.
5. wxCRP, http://www.xs4all.nl/~jorgb/wxcrp, a template generator for Microsoft Windows®. Some templates are provided for automatically generating wxGuiTesting test suites with wxCRP. Optional.
6. Bakefile, http://www.bakefile.org, a cross-platform builder of native build chains. Build chains are provided for Microsoft Visual C® nmake, Microsoft Visual Studio 6® project files, and GNU autoconf. If you need to create other build chains for your toolset, you'll need bakefile to do so.
7. DOxygen, http://www.doxygen.org, a source-code documentation system. You'll need this to build the class documentation into a nice set of html pages with pretty inheritance graphs. Optional.
WXWIN=[DRIVE:] VTK_DIR=[DRIVE:] (if you're going to use VTK)
If the DLLs for wxWidgets, CppUnit and VTK aren't already on your path, fix that too while you're at it.
Navigate to build/msw. You'll find there two files, config.vc and makefile.vc. Edit config.vc to define the various variables. You'll need to set the WX_SHARED, WX_DEBUG, WX_UNICODE, WX_MONOLITHIC, and WX_VERSION to match a wxWidgets library which you have installed already. SHARED, UNICODE, and BUILD set the parameters for the wxGuiTesting library and test applications. If you're using VTK, set USE_VTK to TRUE.
Now run nmake -f makefile.vc. The library and executables will be build in the present directory.
CPPUNIT=[DRIVE:] CPPUNIT_LIB=cppunit library name without extension, e.g. cppunitd_dll
You'll find the solution and project files in build/msw; open MSVS and load wxGuiTesting.sln or wxGuiTesting.dsw.
Now comes the fun part, because there's no automatic way to configure MSVS.
First select from the list of builds the one which matches your wxWidgets installation and build intentions (For example, DLL Unicode Debug Multilib USE_VTK=0).
If you're using a build with USE_VTK=0, it's prudent to open Configuration Manager (select the solution, then right-click: It's on the context menu. It's also available from the property pages) and make sure that the VTKUnitTest project isn't selected for building.
If you set up the environment variables correctly, you're ready to go. Build the solution (either from the Build Menu or by pressing F7 on the keyboard).
../configure make make install
If you want VTK support, specify --with-vtk=/path/to/VTK. If you're using a version of VTK other than 5.0, specify --with-vtk-version=#.# (replacing #.# with the actual version number, of course).
The test and sample apps will stay in your build directory (in the bin subdirectory).
MacOSX note: The Makefile can build app bundles for you, but you need to tell it where your wxWidgets sources are, e.g.
../configure WXSRCPATH=/usr/local/src/wxMac-2.8.6
By default, configure will set SHARED, UNICODE, and DEBUG to match the primary library found by wx-config. If you want otherwise, tell configure (e.g., `../configure DEBUG=0 to build a library without symbols against a debug version of wxWidgets).
On systems other than Macintosh OS-X version 4 (Tiger), you may want to modify the WX_CXXFLAGS in the Makefile to replace -I with -isystem. This will suppress the amazing quantity of warnings emanating from wxWidgets headers. Tiger (and maybe Leopard, not yet tested) has problems with -isystem which while it suppresses the warnings also interferes with linking, so this isn't a universal solution. On the other hand, wxMac seems to be a bit cleaner than wxGTK in regards to warnings.