2017-02-28

That starter git project? Don't stop there...

Two-and-a-half months ago, I posted a 10-step git starter. And I felt good, like I had probably made someone's life a little easier.

I also used it within a matter of weeks for the beginning of a "Coding Dojo"-ish project that my sons (one in the industry already, one about to graduate from SFU in Computer Science, one just in his first year) and I are working on together. Early on in that process, I saw a significant problem with the starter. There was also a significant gap in the how-to-use-this example script. Let me fill in that gap first, and then, later I'll show how to fix the problem.

The gap came in two parts as a result of running the example at home, where all the development boxen run Linux (arch, and fedora -- what a lot of typo-squats there are on fedora, though!). The first part of the gap came in the way I used re-directed cat to create the starting versions of all the files -- something that using Cygwin would have fixed easily enough. But the second problem, the real one, came up in the block after the 10 steps.

On Linux, I could use the default "Unix Makefiles" generator without specifying it at all. Under Cygwin, perhaps that would work as well, but for native Windows builds, especially where the system has several versions of Developer Studio installed (as my Windows development boxes at work often have), you'll want to choose a specific version under which to create solution files.

But wait, you say, I thought CMake was a build system!? Well it is, but not quite. Strictly speaking, it's more a meta-build system. You specify what's required to build what you want in CMakeLists.txt files, but then CMake generates build scripts according to the set of compilers you have on the system. It made the most sense for the project CMake was originally written to support, and given the differences in available functionality on the different platforms, with the different tool chains, it's probably the best choice. The compiler vendors know best what their build system wants. CMake knows how to build build scripts for the build systems listed here. I say call it a win and move on.

If you're building on Windows, and you're using Developer Studio 2013, and you've got both CMake and Developer Studio location on the PATH you would follow step 10 with...

----------------------------------------------------------------------------------------
mkdir build
cd build
cmake -G "Visual Studio 12 2013" ..
msbuild starter.sln /p:Configuration=Release
----------------------------------------------------------------------------------------

I'll verify this when I have an in-house Windows development system up and running, but even if I've messed that up, you should be able to open a ".sln" file from within the build sub-directory in Developer Studio and build and debug everything from there. Once a release version has been built, you should be able to run the resulting command line "tool" and starting "test", from within the build directory as

----------------------------------------------------------------------------------------
.\Release\starter.exe
.\test\Release\testStarter.exe
----------------------------------------------------------------------------------------

And you'll be able to run the resulting test with ctest, thus:

----------------------------------------------------------------------------------------
ctest -C Release .
----------------------------------------------------------------------------------------

The problem, which I'll address in another installment lies in where the test directory is in the example vs. where better practice might put it. Don't worry. Git and your favourite text editor will make this easy, too.

No comments: