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...
No comments:
Post a Comment