• GNU Make
• Perforce Jam/Boost.Build (based on Boost.Jam which is in turn based on Perforce Jam.)
• Apache Ant
• SCons

Initially, I had been using GNU Make, but I ran into some limitations with it. As a quick aside, I suspect that it is possible to use Make to do all of what I’m going to mention, however I’m no master of esoteric art of writing Makefiles, and consequently figuring these things out in Make would have been no easier than learning a new build system. The single biggest feature I wanted was the ability to have several different build configurations, namely release builds and debug builds. The only way I know of to do this in Make would involve setting environment variables when make is invoked; e.g: CFLAGS=-g make.
Additionally, I wanted to be able to have all intermediate files as well as output files be located in a different subdirectory than the source code. That is, if all code is in src/, the build output would end up in build/.

First I looked at Perforce Jam as well as Boost.Build, but I found the combination of odd syntax and minimal documentation to be sufficient to move on.
Next, I considered Apache Ant, but given that I try to avoid Java based tools when I can, as well as the XML based configuration files, I opted to but Ant on the back burner while I explored other avenues.

Finally, I came to SCons, a Python based system which uses Python scripts to control the build. This alone sets it out from all the other options I examined, as it does not try to invent a new language, but rather simply reuses a general purpose language. SCons has the ability to do what I wanted: varying configurations and separate source and build directories, coupled with a configuration language I happen to already know. That being said, I do have some problems with SCons. It tries very hard to be multi-platform, and as such tends to require a bit more of an abstract approach when defining things like compiler parameters. This is all well and good, but it feels a bit like to much control is being taken from me. Additionally, it feels a little bit slow, due in large part to how it handles dependencies and determines what has changed (it parses source files looking for includes, and uses strong hashes to determine if a file changes rather than timestamps).

Overall however, SCons seems to be the best bet, at least for my needs.

litesql is an object persistence library that uses sqlite as it’s storage backend (although it now also supports MySQL and PostgreSQL). There are two separate components to the system, the library which handles the actual storage mechanism, and the code generator which takes as input an XML specification of your data objects and generates the appropriate C++ classes.

Defining your model and generating the appropriate code is very easy. The XML format is very straightforward, although it limits you to only a handful of datatypes (which actually is a good thing, as it hides details about the storage backend). Additionally, there is support for inheritance between the model objects, and of course litesql supports all the typical relations (one-to-one, one-to-many, and many-to-many). The generator then process your XML specification and outputs two files, yourdatabasename.cpp and yourdatabasename.hpp.

The generated code uses the STL, particularly the string and vector classes, and unfortunately avoids the rather nasty problems that plague all heavily templated code bases–nasty looking syntax and even worse error messages. On the upside, you don’t have to worry about interacting with poorly documented project specific classes that do much the same thing as the STL.

While overall I do like litesql there are a few things that really annoy me. First and foremost, the documentation of the library is sorely lacking. Perhaps the worst case of this comes in attempting to understand how the attributes of class instances work. It seems that they have a type of Field<T>, but in some cases there seem to be overloads that allow you to directly work with this object, e.g. in assignment. However, at other times, you must invoked the value() method of the Field to get to the actual data, e.g. in equality tests.

Finally, my last major problem is that there are (almost) no unit tests. To my mind this is a tremendous problem, particularly for a library. How do the developers know that things are working properly? How do I know that things are working properly? Additionally, while less optimal than true documentation, a set of good tests can give clues as to how things are supposed to work.

Ultimately, without full and proper documentation, it is very difficult to truly judge the library. From what I’ve seen I like it, and it seems to have a lot of promise, but I’m just not sure if it works properly. Given all that, I’d say 80% is a fair judge of the litesql library.

As a computer science student, we get told that there are certain things that we should do when developing code. Some are simple, little things, like documenting code as we write it. Some are a bit more complicated but still readily feasible, such as using version control, or writing test cases. However, other things are much more difficult to do.

Really, the problem comes down to a matter of scale. For instance, issue tracking is a very good idea; it allows us to readily keep track of what needs work. Unfortunately, there is no good way (that I know of at least) to do this on the scale at which we students work (that is, one to circa four people). Sure we could setup our own personal bugzilla or what-have-you. However, not only is this overkill, but there is a rather difficult issue to be worked out: where do I install it so I can access it anywhere I would want to work from?
Alternately, we could use // TODO: type comments to keep track of issues. However, in doing this we no longer have a single central repository of issues. Additionally, by doing this it becomes much harder to get a high level view of the project’s issues.
I see two potential solutions to this. First, as we’re looking at this at the university level, the computer science department could provide these services to students. This would potentially bring up other problems, for instance can I use this system for personal projects, or just assignments? What about privacy? Who can see the issues for a given project?
The other solution, and one I’m thinking about pursuing, is to create a small standalone application to handle issue tracking. To work well it would need to be able synchronize/merge issues between instances (thus allowing you to work from multiple systems). Additionally, it would need to support multiple users, or really merging from untrusted sources. Finally, some sort of integration with source control systems would be nice.

Suppose now that this individual then inserted some malicious code into his compiler. The effect of this could be to insert a back door of some kind in everything it compiled. Additionally, suppose it detected when it was compiling a new compiler and modified this new compiler to do much the same thing. Finally, to make it’s modifications undetectable, all memory and disk reads were modified to make it impossible to see the back door.

Such an attack would be undetectable, completely and utterly. Of course, it would also complicate this original compiler so much that peer review would immediately catch that something strange was going on. Unless they were all in on it… (-;

Additionally, after talking to this professor about it, I tried to figure out how, exactly, I would do this, and I’m stumped. To insert a back door in all compiler output would be simple enough, however to detect that a new compiler was being built, and then modify it appropriately… I don’t that this is possible. In a fairly abstract sense, all programs are compilers, that is they take some input in one language and translate it to another language. True, there are certain ways of writing compilers that are used fairly often (e.g. finite state machines to extract lexemes, recursive descent parsing, etc.) however there’s no reason one must build a compiler in these ways. And then there’s the whole question of how to modify the code to be just as malicious as it’s predecessor. Essentially, this first generation compiler would have to understand how it’s input would function, and such semantic analysis would be impossible, I think.

So, while it’s a fairly nifty idea, the notion of a fundamentally untrustworthy computer infrastructure, due to a single bad compiler, is quite silly.

Wherein I try Subversion

Of course, this turned out to be something of a trial in and of itself. Not knowing much about SCM systems at the time, I turned to what I heard the most about (namely on Slashdot…). At this time Subversion was becoming the “big deal,” and nearing a 1.0 release. So I decided to give it a try. It works well enough for me that I still use it to this day, although I’m becoming more and more annoyed with it.

Time: Passes; Time: All Wounds Heals

So this was several years ago that I opted for Subversion for the wonderful reason that it was popular. In the intervening time I had some exposure to other systems. For instance, in the Software Engineering course we used CVS extensively, and I came to truly and fully appreciate the work of the Subversion team. Additionally, the professor who maintains the Math/CS divisional servers and sponsors the local Linux User Group discovered darcs and sparked a fair bit of discussion, both in the LUG and amongst the CS student body as a whole, about distributed development models in general.

An Aside Regarding Centralized and Distributed Development

While the two basic models of development have been understood for years (that is, the Cathedral and the Bazaar) it is only recently (at least to the best of my knowledge) that development tools have really started to diversify along the same lines. In particular, version control systems have split into two basic categories, those focusing on centralized development, and those focused on distributed development (of course these aren’t truly mutually exclusive, one tool can do both, and one workflow can actually accomplish both fairly readily).
The centralized tools, like Subversion and CVS, are organized around a client-server model. There is a single storage location for all project history and individual developers have local access to, at most, their changes and the version upon which those changes are based. This works just fine in settings where developers are always connected and there is a central authority managing the code.
However, in disconnected environments, or with projects along the lines of the Linux kernel, where there is no true central authority, this model doesn’t work so well. To address this issue more distributed version control systems have been developed, for instances, darcs and Bazaar. These tools generally give the individual developer his own repository, stored on his local machine. He then develops against this, committing changes to it as needed. Then as needed those changes can be pushed to other developers or some upstream source, if it exists.

Returning to Our Story

So having been exposed to another way of thinking about SCM, I start to wish for certain changes to Subversion. To better illustrate this, lets look at my work environments:

• First, when I’m at my apartment I work using my desktop, a system running Windows XP (and Cygwin, so I can also use UNIX-y tools if I need to). This system has a permanent, fast ethernet connection to the server where repositories live.
• Second, I like to get away from the apartment at times, so I’ll work with my laptop, a system running Windows Vista (again with Cygwin). Provided I can get wireless access, I have a slow, flaky connection to the source code repositories via residential DSL. Unfortunately, some of the more interesting places to go around here don’t exactly have wireless access.
• Finally, there’s a nice lab on campus for math/CS majors only (we call it the Nerdery (-: ) and I like to work there, particularly on group projects. The systems there are a mix of Windows XP, OS X, and thin clients that connect to the communal Linux servers. Of course, from any of them it’s easy to shell or VNC to those same communal servers. But, again, I have the problem of repository access over a poor quality connection.

At first glance it looks like a distributed system would be ideal. However, I actually like certain aspects of the centralized approach–namely that there is a central, authoritative repository. I don’t need or want a system so distributed that I have to go through anything beyond an update to get my latest changes. Also, most distributed systems are designed primarily as command line tools, and if they have GUI components they’re built for Linux systems. Now, I can handle that, if I have to, but I rather like TortoiseSVN (an interface for Subversion that integrates with the Windows shell) and I’d like to have that with whatever system I use.

As it stands I don’t have a good solution to my dilemma. However, Bazaar looks fairly promising. There’s a plugin for it that allows transparent branching/merging with Subversion repositories, unfortunately it’s pretty much impossible to get it working with Windows right now, as it requires either a development version of Subversion or a patched version the 1.4.x tree. Additionally, there is no Windows shell integration for Bazaar–yet. It looks like they intend to create that fairly soon. I hope.

1
2
3

a = """a = %c%c%c%s%c%c%c
print a %% (34, 34, 34, a, 34, 34, 34)"""
print a % (34, 34, 34, a, 34, 34, 34)

Now run it. The output is the program itself!
For double the fun, try this at a command prompt:
python quine.py | python - | python - | python -
(ad nauseum)
Super Cool!

1. On my laptop I recieved messages about failure to create COM objects (eg “Unable to create VmdbCore object: Class not registered”). Trying to register the appropriate DLL, vmdbCOM.dll, by hand only resulted in failure and an error code of 0×8007007e. After much searching the net, I found that I needed to register atl.dll. Here’s what I did:
   1. regsvr32 c:\windows\system32\atl.dll
   2. regsvr32 “c:\Program Files\VMWare\VMWare Server\vmdbCOM.dll”
   3. regsvr32 “c:\Program Files\VMWare\VMWare Server\vmappsdk.dll”

   After that, it worked wonderfully.

2. If you want to use the web interface, you’ll need to have IIS installed before you install VMWare Server. If you’re like me and only realize that you don’t actually have IIS installed until after you install VMWare, no worries. Simply install IIS and then use the Repair functionality of the VMWare Server installer.
3. Using IIS 5 on Windows XP Pro, I was informed that the VMWare IIS site was setup correctly, but was unable to start. The solution I found was to stop the Default Site using the IIS manager snap-in and then start the VMWare Management Interface site. My guess is that IIS on XP is crippled to allow only one site running at a time.
4. To access VMWare Server from another machine you’ll need (by default) the following ports open on the server system:
   1. 8222 (For the VMWare Management Interface website)
   2. 8333 (For the SSL encrypted version of the VMWare Management Interface website)
   3. 902 (To connect with the VMWare Virtual Machine Console application)

Aside from those issues, it’s been wonderfully smooth sailing thus far.