We had this puzzling behavior of a compilation step failing on all our Windows buildslaves, when the same compilation would succeed when performed interactively. After long searching and meditating, we found out. The issue was that Windows environment variable change case when the user is logged in interactively or as the user impersonating a service. @#!%&$ !!!!
For example, the interactive user sees:
CommonProgramFiles=C:\Program Files\Common Files
but the service sees:
COMMONPROGRAMFILES=C:\Program Files\Common Files
This behavior is consistent across Windows XP, Windows 7 and Windows 8 Consumer Preview. The behavior is likely to have no effects in most cases, since in Windows pretty much everything case-insensitive … but, but there are exceptions to this rule, for example the Registry Redirector is case sensitive. And (what hit us) bjam is case-sensitive when accessing the operating system environment variables with the os.environ command, as some users already found out.
Since the buildslaves run as a service impersonated by a non-privileged user as usual on Windows, so bjam was unable to find the required headers.
The solution was to add this code to out Jamroot.jam:
local commonProgramFiles = [ os.environ "CommonProgramFiles(x86)" ] ; commonProgramFiles ?= [ os.environ "CommonProgramFiles" ] ; commonProgramFiles ?= [ os.environ "COMMONPROGRAMFILES(X86)" ] ; commonProgramFiles ?= [ os.environ "COMMONPROGRAMFILES" ] ;