seandenigris.com

I got tired of manually adding them, so here’s a little script…

set list_lib to load script alias “Path:To:List Utilities.scpt”

tell application “Xcode”

– Get file name of front-most document (via window)

set header_file_path to associated file name of window 1

 

– Go back and get the source file using the name

set header_file to first source document whose path is header_file_path

– Turn the file into a list of lines to
— find the insertion point for the inclusion guard

set lines_of_header to paragraphs of text of header_file

– Create the inclusion guard based on the file name

set inclusion_guard_token to first word of (get name of header_file) 
& “_H_INCLUDED_”

set guard_start to “\n#ifndef “ & inclusion_guard_token 
& “\n” & “#define “ & inclusion_guard_token & “\n”

 

– Insert the start of the guard

set lines_of_header to list_lib‘s list_insert(lines_of_header, guard_start, 9)

– Insert the end of the guard

set end of lines_of_header to “\n\n#endif”

– Set the revised contents of the file

set text of header_file to (lines_of_header as text)

end tell

List Utilities.scpt (code from AppleScript: The Definitive Guide, 2nd Edition:

on find_in_list(what, L)

repeat with i from 1 to count L

if item i of L is what then

return (a reference to item i of L)

end if

end repeat

return

end find_in_list

on list_insert(L, what, ix)

if ix = 1 then

return {what} & L

else

return {item 1 of L} & list_insert(rest of L, what, ix - 1)

end if

end list_insert

I’m exploring Hippomocks, a C++ mock library.

Installation

The library supplies a test suite for compilers not known to be supported.  GCC is listed, but I think Apple’s version is a little different than standard GCC, so I’ll run that.  Pretty easy in Terminal:

1. “cd /path/to/Hippoocks/HippoMocksTest/”
2. “make test” (there’s also a test0x, but it requires >= GCC 4.3, which is confirmed when my Mac doesn’t recognize “-std=c++0x”)

And… errors  But easy ones to fix…

cc1plus: warnings being treated as errors

../HippoMocks/hippomocks.h:139: warning: ‘class func_index’ has virtual functions but non-virtual destructor

is_virtual.cpp:4: warning: ‘class IL’ has virtual functions but non-virtual destructor

test_class_mock.cpp:24: warning: ‘class IG’ has virtual functions but non-virtual destructor

…

[TOTAL](30/30)

[OK](30/30)

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

As excited as I was about wt, I was equally worried that I would not be able to get wt set up correctly since I use a shared host.  

First, shout out to downtownhost.com for all the support.  They use litespeed, for which there seems to be no setup instructions online.  

We finally got it going by:

1. adding the Wt app as a FastCGI “External application” in litespeed’s admin interface
2. then /path/to/relevent/folder/under/webroot/.htaccess: AddType application/x-httpd-[insert name of ext app here] [insert file extension]

I would prefer to use a SetHandler instead of the dummy file required by AddType, but I’m really splitting hairs now – it’s working, so I’ll put it on my list of things I’m not doing now and start coding already!

UPDATE: The above approach is unworkable because:

1. My shared host uses Apache configurations (not the Litespeed admin console) to set up virtual hosts
2. In it’s current version (4.0.1), Litespeed does not support Apache configurations for FastCGI (Litespeed support said that they will be implemented in the next subversion.

What this means is that my app would be started by the Litespeed web server under its user and group IDs, not suExeced like PHP or CGI apps.  Because I do not own the process, every time there is a problem with it (or I update the binary), I would have to contact customer support and have them manually kill the processes.  Obviously, this would not work.

However, it doesn’t matter anyway because…

After several emails with Koen from Wt, I found out that, for a public site, they recommend using the built-in wthttp server with the public web server (e.g. Aapche) as a reverse proxy.  I can not do for the same two reasons – my hosts method of virtual hosting and the limits to Apache configurations in Litespeed (in this proxy configs)

So, I’m switching to one of my host’s servers with Apache, which can easily be configured as a reverse proxy with wthttp (the user will communicate with Apache, which will forward all requests to wthttp, without the user ever knowing that anything is going on behind the scenes).

I love the idea of the wt toolkit: create an application, just like any desktop app.  Then, use wt for the “GUI” which hides all the web technologies and automatically handles the communication between the web server and my app.  wt will determine the best way to display the UI compatibly with the user’s browser.

OMG!  I can use my existing C++ skills to create awesome web apps without wasting time learning the panoply of ever-evolving web technologies – AJAX, HTML, Javascript – all taken care of by people who know them far better than me.

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.”

After my expatpp adventure, I took a sharp turn and switched to expatmm.  It too is a C++ wrapper to expat, but it seems more up-to-date (working with the latest version of the expat library) and has replaced expatpp on the expat 3rd party links.

It works great out of the box on Mac OS X 10.5.6.  It built and installed (using configure and make) with only one small problem – I had to change ExpatMM-version.cpp to hardwire the version # in.  Once that change was made, I included and linked to the lib from Xcode with no problem.