VC9 compile step assumes PlatformSDK is installed

[philippem]

• buildbot slave 0.8.3 on xp, using VC9 compile step.
• devenv fails with a warning/error, because the VC9 compile step sets the LIB path to a directory that would be created if you had installed the v2.0 platform sdk (not sure the exact version, there are several).
• I don't have any of the platform sdks installed on the buildslave.
• to work around this, I created the empty directories c:program filesmicrosoft visual studio 9.0SDKv2.0lib and c:program filesmicrosoft visual studio 9.0VCPlatformSDKlib, and the compile passed.

It would be good if the buildbot compile step either (a) did not make this assumption or (b) was robust enough to deal with its absence

build step:

f5.addStep(VC9(projectfile="IXXX\AutomatedTests\AutomatedTests.sln", config="Debug", mode="build"))

error messages in build step output:

'devenv.com' 'IXXX\INDMA.sln' '/Build' 'Debug'
 in dir c:uildbot	runk-continuousuild (timeout 1200 secs)
 watching logfiles {}
 argv: ['devenv.com', 'INgrooves\INDMA.sln', '/Build', 'Debug']
 environment:
  ALLUSERSPROFILE=C:Documents and SettingsAll Users
  APPDATA=C:Documents and SettingsautomatedqaApplication Data
  CLIENTNAME=NSL-MMARCANO
  CLUSTERLOG=C:WINDOWSClustercluster.log
  COMMONPROGRAMFILES=C:Program FilesCommon Files
  COMPUTERNAME=YAMTESTING
  COMSPEC=C:WINDOWSsystem32cmd.exe
  FP_NO_HOST_CHECK=NO
  INCLUDE=C:Program FilesMicrosoft Visual Studio 9.0VCINCLUDE;C:Program FilesMicrosoft Visual Studio 9.0VCATLMFCinclude;C:Program FilesMicrosoft Visual Studio 9.0VCPlatformSDKinclude;
  LIB=C:Program FilesMicrosoft Visual Studio 9.0VCLIB;C:Program FilesMicrosoft Visual Studio 9.0VCATLMFCLIB;C:Program FilesMicrosoft Visual Studio 9.0VCPlatformSDKlib;C:Program FilesMicrosoft Visual Studio 9.0SDKv2.0lib;
  LOGONSERVER=\YAMTESTING
  NUMBER_OF_PROCESSORS=2
  OS=Windows_NT
  PATH=C:Program FilesMicrosoft Visual Studio 9.0Common7IDE;C:Program FilesMicrosoft Visual Studio 9.0VCBIN;C:Program FilesMicrosoft Visual Studio 9.0Common7Tools;C:Program FilesMicrosoft Visual Studio 9.0Common7Toolsin;C:Program FilesMicrosoft Visual Studio 9.0VCPlatformSDKin;C:Program FilesMicrosoft Visual Studio 9.0SDKv2.0in;C:Program FilesMicrosoft Visual Studio 9.0VCVCPackages;C:Program FilesCollabNetSubversion Client;C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem;C:Program FilesMicrosoft SQL Server80ToolsBinn;C:Program FilesMicrosoft SQL Server90Toolsinn;C:Program FilesMicrosoft SQL Server90DTSBinn;C:Program FilesMicrosoft SQL Server90ToolsBinnVSShellCommon7IDE;C:Program FilesTortoiseSVNin;C:Python25;C:Program FilesMicrosoft SQL Server100ToolsBinnVSShellCommon7IDE;C:Program FilesMicrosoft SQL Server100ToolsBinn;C:Program FilesMicrosoft SQL Server100DTSBinn;C:WINDOWSsystem32WindowsPowerShellv1.0;C:flexflex_sdk_4.0.0.13875in;c:xunit-1.6.1;
  PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1
  PROCESSOR_ARCHITECTURE=x86
  PROCESSOR_IDENTIFIER=x86 Family 6 Model 26 Stepping 5, GenuineIntel
  PROCESSOR_LEVEL=6
  PROCESSOR_REVISION=1a05
  PROGRAMFILES=C:Program Files
  PWD=c:uildbot	runk-continuousuild
  SESSIONNAME=RDP-Tcp#1
  SYSTEMDRIVE=C:
  SYSTEMROOT=C:WINDOWS
  TEMP=C:DOCUME~1AUTOMA~1LOCALS~1Temp
  TMP=C:DOCUME~1AUTOMA~1LOCALS~1Temp
  USERDOMAIN=YAMTESTING
  USERNAME=automatedqa
  USERPROFILE=C:Documents and Settingsautomatedqa
  VS100COMNTOOLS=C:Program FilesMicrosoft Visual Studio 10.0Common7Tools
  VS90COMNTOOLS=C:Program FilesMicrosoft Visual Studio 9.0Common7Tools
  WINDIR=C:WINDOWS
 closing stdin
 using PTY: False

Microsoft (R) Visual Studio Version 9.0.30729.1.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: FluorineFx-3.5, Configuration: Debug Any CPU ------
1>FluorineFx-3.5 -> c:uildbot	runk-continuousuildINgroovesFluorineFxinDebugFluorineFx.dll
2>------ Build started: Project: INPlugin, Configuration: Debug Any CPU ------
2>INPlugin -> c:uildbot	runk-continuousuildINgroovesINPlugininDebugINPlugin.dll
3>------ Build started: Project: CommonCore, Configuration: Debug Any CPU ------
3>c:WINDOWSMicrosoft.NETFrameworkv3.5Csc.exe /noconfig /unsafe+ /nowarn:1701,1702 /errorreport:prompt /warn:4 /define:TRACE;DEBUG;EN /reference:c:WINDOWSMicrosoft.NETFrameworkv2.0.50727System.Data.dll /reference:c:WINDOWSMicrosoft.NETFrameworkv2.0.50727System.dll /reference:c:WINDOWSMicrosoft.NETFrameworkv2.0.50727System.Drawing.dll /reference:c:WINDOWSMicrosoft.NETFrameworkv2.0.50727System.Windows.Forms.dll /reference:c:WINDOWSMicrosoft.NETFrameworkv2.0.50727System.Xml.dll /debug+ /debug:full /optimize- /out:objDebugCommonCore.dll /resource:objDebugINgrooves.Common.Images.resources /resource:objDebugINgrooves.Common.Strings.resources /resource:Imagesingrooves_generic.gif,INgrooves.Common.Images.ingrooves_generic.gif /resource:Imagesonedigital_generic.gif,INgrooves.Common.Images.onedigital_generic.gif /target:library /warnaserror+ Bits.cs Chars.cs CommonCore.cs ContainersContainer.cs DatabaseIDBBase.cs Images.cs PropertiesAssemblyInfo.cs Strings.cs
error CS1668: Warning as Error: Invalid search path 'C:Program FilesMicrosoft Visual Studio 9.0VCPlatformSDKlib' specified in 'LIB environment variable' -- 'The system cannot find the path specified. '
error CS1668: Warning as Error: Invalid search path 'C:Program FilesMicrosoft Visual Studio 9.0SDKv2.0lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified. '

[tom.prince]

I don't have access VS9, to figure out what should be done to fix this, if anything. My guess would be that it is the project that is setting those paths, rather than anything buildbot is doing.

[dustin]

Callek, any suggestions here?

[philippem]

It is buildbot that is setting the paths, in buildbotstepsvstudio.py in the VC9 build step. Depending on what version of MS visual studio is installed on the slave, and which optional SDKs, these paths may or may not exist. I had to do the above workaround (create empty dirs under c:Program Files...) to make the compile pass.

[philippem]

One possible fix is to determine a 'canonical' set of lib paths that should exist on a generic VS installed build slave, but there are multiple versions of the SDKs. Another fix is to create custom build steps derived from the provided VS build steps that work in the particular build slave environment. Maybe there is another way to determine the list of paths dynamically.

My guess is that the path list in vstudio.py was created based on one particular VS-installed machine.

[dustin]

In my opinion there are too many subclasses already. The best option is automatic detection (which should be as simple as some stat commands, right?), and failing that or if the autodetection doesn't work, allowing the paths to be specified as constructor arguments.

[philippem]

Automatic detection could work, but if multiple versions of SDKs are installed on the machine and the user wants a specific version, then there may be unexpected surprises.

Maybe it's better to not put any default SDK paths, and let the user add the right paths in his or her own custom build step.