We're running our unit tests as a post-build step in our builds. Now I've run into a problem with this on our autobuild machines that automatically pull and build every revision in svn.

The autobuild script pulls down a revision, does some setup and then calls devenv.exe /build on it. This, in turn, will build everything and then try to run the tests. The build gets stuck and never completes.

If you build the solution manually, what happens at the run tests point is a popup dialog box saying the test executable is not a valid Win32 application. I'm assuming the autobuilds somehow get this box as well, but hidden away in a non-interactive session somewhere.

I've had two ideas for a solution this far:

Check in a test-runner application which tries to run the tests and detects the failure. This is undesirable though since this would mean creating this extra kludge of code and adding it to be used only on windows builds etc.

Somehow test if windows is 32-bit or 64-bit in the build scripts (we're running cmake), and simply don't run the tests if they wouldn't work. This is preferable, but requires a way of checking if windows is 32-bit or 64-bit, preferably without having to check in another "test-windows-type" helper tool.

Any further ideas or hints on how to implement suggestion 2 would be much appreciated.

Update: Note here: This is a cross-compile running on a 32-bit machine but compiling a 64-bit exe. If I could just check properties of the compiler, there wouldn't have been a problem. But I'm after properties of the build machine, not of the build itself, which is clearly 64-bit.

Well, there are other good reasons for having the build run on XP. Preferably would do both, but if I have to choose I'll have to go with the 32-bit box. And I do have to choose at the moment, sadly.
–
slicedlimeSep 7 '09 at 12:52

I found out one way to identify if the system is 64-bit or not, which should be possible to access from cmake. It feels as a rather ugly hack though that could break on any random version of windows, so I'd still rather find another way.

The %ProgramFiles(x86)% environment variable only exists in 64bit OS versions.