bda’s blog

I added a rule to rebuild my tags file whenever the sources change. It took me way too long to figure this out – I was very surprised that a google search for ‘bjam ctags’ turned up nothing.

make tags : [ glob *.cc ] [ glob *.h ] [ glob lib/*.cc ] [ glob include/*.h ] : @ctags ;
actions ctags
{
    ctags $(>)
    cp tags $(<)
}

I can’t figure out how to make targets appear in the project root instead of the build dir. However bjam runs ctags in the project root, so ctags will do the right thing. I copy the generated tags file to the location bjam expects so versioning still works. Note that $(>) refers to the sources and $(<) to the target. See Chapter 5->Custom Command for more info. There is also a nofile rule, which runs a command unconditionally.

Meanwhile I discovered that I could get rid of my $HOME/user-config.jam. I moved it to project-root.jam in my project root, renamed my Jamroot to Jamfile, and then it worked as before. Interestingly I can also rename project-root.jam to Jamroot, so I have a Jamroot and Jamfile in my top level project directory. Maybe project-root.jam and Jamroot serve the same purpose? In any case I prefer this setup because it removes clutter in my homedir and those settings really are project specific.

The official documentation neglects to mention that you must import the testing module for any of the testing rules to work. I put ‘using testing ;’ in my user-config.jam.

I had no trouble with the ‘unit-test’ rule, which has the same syntax as ‘exe’ but also runs the program and checks the exit status. However if you want to pass arguments or input files, you must use the ‘run’ rule, which has different syntax and seems fail if there is an exe rule for the same program. Here’s my run rule, and the corresponding exe and unit-test rules for reference:

Continue reading ‘Unit Testing with Boost.BuildV2/bjam’ »

Lately I’ve found maintaining Makefiles tedious, even for small projects. Much can be done with implicit rules, but header file dependencies must still be specified manually (or so I though – more on this later). For a small project, maybe you only have five or so of these rules. However there is no reason to manage these manually, and for small projects I am more lazy and feel more entitled to a completely hassle free build system. If it’s so simple, why should I be doing any work?

What I want is a build system that handles include dependencies automatically, allows me to build to a separate directory, and allows me to clean without specifying all the files that need to be deleted. I also really like compact and easy to understand syntax. Advanced features that are useful for large projects are also a plus – many large projects start out small.

I created build files for SCons, BJam/Boost.Build V2, and CMake. For each tool, I will list my build file(s) and discuss my impressions. Note that the analysis is necessarily shallow – I am mainly concerned with how well they work on small projects with very modest build needs, and I have spent very little time with each system. I also discuss a solution to the header dependency problem using GNU Make.

Continue reading ‘make alternative for small C/C++ projects’ »