Minimizing impact

While code-reviewing proposed changes to the HPCC-Platform project, I recently saw one that seemed questionable. I'm paraphrasing but the code that has been added was something like this:

#ifdef __APPLE__
some change that didn't seem particularly Apple-specific
#endif

I questioned the change - why was it needed and if so why was it only needed on Apple systems - and was told (in effect) "Technically, the change is correct for other platforms too, but it's not necessary because they don't check, and I wanted to minimize the impact".

There are times when it's appropriate to make a change in such a way that it "minimizes impact" at the expense of future maintainability and code readability - primarily in cases where an emergency patch is being made in a stable branch - but on an active code branch it's almost always a bad idea. You now have two versions of the code, one more correct than the other, and both needing to be maintained.

If you believe that a change you are proposing improves the code, then why would you want to minimize the amount of improvement? And if it doesn't improve the code, then you shouldn't be proposing it (and I won't be accepting it!)

CMake and Visual Studio 2010

We've been using CMake to simplify the process of targetting multiple platforms in the HPCC-Platform project at HPCC Systems for a while now, and it's been working very nicely, in general.

However one thing that HASN'T worked nicely was when we tried to use Visual Studio 2010 in place of Visual Studio 2008 that we had been using for the past few years. In theory it should have been as simple as selecting a different generator when running CMake, and CMake would take care of all the differences - that's what it's there for...

 Up to this point we've just shrugged, told our developers to use Visual Studio 2008 (which I much prefer to Visual Studio 2010 anyway) for Windows testing, and put off the problem to be fixed another day. However with the impending release of the code as open source, getting it to work with Microsoft's latest (though maybe not greatest) became more urgent so I started looking at it again.

At first I was convinced that Visual Studio 2010 was simply broken as far as custom build rules were concerned. If a project had a single custom build step in it, it was fine, but with more than one it would only perform the first unbuilt step each time the project was built, so I had to build some projects multiple times to get them to complete. However after much scratching my head I finally worked out what was really going on.

The salient points here are:

• The custom build program I am executing is a batch file
• Visual Studio 2010 generates (then executes) a single batch file for all custom build steps in a project
• If a batch file executes another batch file without specifying CALL, control never returns to the original batch file

In Visual Studio 2008, it seems that each custom build step is executed independently and thus the problem does not occur.

I hesitate to describe this as a bug - certainly Microsoft might well claim that having to put the call on when a custom build step references a batch file is expected and by design, and CMake may equally claim it's not up to them to insert a 'call' in the Visual Studio files they generate (if they can even tell when they would need to). But it is certainly a gotcha...