views:

396

answers:

5

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:

  1. 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.

  2. 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.

A: 

You should be able to check the CMake generator which I think is different for 32/64 bit windows.

JesperE
The CMake generator is 64 bit since we're compiling a 64 bit exe... so that doesn't really help. This is a cross-compile running on a 32-bit box.
slicedlime
A: 

You can check the CMAKE_SIZEOF_VOID_P variable in your build script to detect the type. See documentation here. Then you can skip running the tests if this variable is 32.

Update: Sorry I overlooked your real issue. I think the best approach may be to apply a try-run test and use the RUN_RESULT_VAR to determine if the app ran successfully.

Hole
The size of a pointer reflects the settings of the build (just like the cmake generator, like someone else suggested), not the properties of the build machine.
slicedlime
A: 

Not an answer to the the specific question you asked, but you should perhaps consider building your app on an x64 machine, which could run 32-bits tests as well as 64-bits tests...

Mac
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.
slicedlime
There are 64bit editions of XP.
Chris Becke
Sorry that was a bit unclear, that should have said having it run on 32-bit XP.
slicedlime
A: 

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.

slicedlime
+1  A: 

Check the %PROCESSOR_ARCHITECTURE% environment variable :

  • x86 on a 32-bit machine.
  • AMD64 on a 64-bit machine (cf. here).
Mac
Sounds like I was looking for. Only weirdness I can find with this is that running cygwin seems to overwrite the value with x86.
slicedlime