seandenigris.com

In my quest to automate all repetitive tasks, setting up a Xcode project for unit testing (using Boost.Test) is in my crosshairs.  I’m in the process of adopting BDD, so you’ll see that terminology mixed with that of unit testing.

Plan

1. List out all the manual steps.  I started with the process described by Richard Dingwall in a very nice tutorial here.
2. Implement task in Applescript

Manual process

Ok, so here’s what I do when I start a new C++ project…

1. File->New Project…
2. Add Group “Features” @ [project-directory]/Features
3. Add Group “Specifications” @ [project-directory]/Specifications
4. Add Group “Boost Test Common” @ [project-directory]/Boost Test Common
5. Add XcodeLogFormatter.h (allows Boost.Test reports to be properly displayed in Xcode build results; see below) and run_tests.cpp (Boost.Test’s main function) to Boost Test Common
6. Add Features Target
   1. Add->”New Target”
   2. BSD->Shell Tool
   3. Name: Features
   4. Add run_tests.cpp to “Compile Sources”
   5. Add “/usr/local/include/boost-1_38/” to “Header Search Paths” of Features Target
   6. Add->New Build Phase->New Run Script Build Phase
   7. Script: “${TARGET_BUILD_DIR}/${EXECUTABLE_NAME}” (this causes the Features to be run every time the target is built)
7. Add Specification (i.e. unit tests) Target: repeat step 6 above for “Specifications”
8. Add->Existing Files->[boost unit test library]; check Targets: “Features” and “Specifications”

Applescript

Finally done!  Here’s the script and Xcode library script.

Not Doing Now

As I work, I make a list of things that would be nice to have, but are not important enough to think about right now and would take me away from my task:

1. Put Boost Test Common files in a commonly accessible include folder

Source Code

XcodeLogFormatter.h (from http://richarddingwall.name/category/xcode/):

#include <boost/test/included/unit_test.hpp>

struct xcode_log_formatter :
public boost::unit_test::output::compiler_log_formatter
{
// Produces an Xcode-friendly message prefix.
void print_prefix(std::ostream& output,
boost::unit_test::const_string file_name, std::size_t line
{
output << file_name << ‘:’ << line << “: “;
}
};

run_tests.cpp (from http://richarddingwall.name/category/xcode/):

#define BOOST_AUTO_TEST_MAIN
#include <boost/test/unit_test.hpp>
#include “XcodeLogFormatter.h”

// Set up the unit test framework to use an xcode-friendly log formatter.
struct xcode_config {
xcode_config() {
boost::unit_test::unit_test_log.set_formatter( new xcode_log_formatter );
}
~xcode_config() {}
};

// Call our fixture.
BOOST_GLOBAL_FIXTURE(xcode_config);

(updated) Check out the finished AppleScripts:
1. main script @ http://seandenigris.com/blog/files/Make%20new%20C++%20project.scpt
2. Xcode handler library script @ http://seandenigris.com/blog/files/Xcode.scpt

By default, Boost builds libraries for your native architecture only.  I’m sure there is a better way, but an easy way I found without manually using bjam is adding “architecture=combined” to the makefile that configure generates.  E.g:

@$(BJAM) $(BJAM_CONFIG) –user-config=user-config.jam –prefix=$(prefix) –exec-prefix=$(exec_prefix) –libdir=$(libdir) –includedir=$(includedir) architecture=combined $(LIBS) install || echo “Not all Boost libraries built properly.”

@#$%#$^$%%$#^#$%#%!!!!!!!!

Love Boost, hate Boost.  You can’t imagine how much time I spent on this.

Ok, much better.  If you install the Boost libraries to an alternate directory (other than usr/local/lib), you will have to jump through hoops to link to the shared versions.

Option #1: Keep Boost in /usr/local/libs.  To link to shared libs, drag them into Xcode.  Done.  (Tip: put a symlink in a visible directory if you can’t see /usr/local/libs)

Option #2: Keep Boost wherever you want and copy the dynamic libs you use into the executable’s directory before linking.  This approach is not recommended.  Your program will only work when the current directory is the directory of the executable.