Opened 10 years ago

Last modified 7 years ago

#1754 new defect

VC9 compile step assumes PlatformSDK is installed

Reported by: philippem Owned by:
Priority: patches-accepted Milestone: 0.9.+
Version: 0.8.3 Keywords: windows
Cc: callek

Description (last modified by dustin)

  • 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:

'' 'IXXX\INDMA.sln' '/Build' 'Debug'
 in dir c:uildbot	runk-continuousuild (timeout 1200 secs)
 watching logfiles {}
 argv: ['', 'INgrooves\INDMA.sln', '/Build', 'Debug']
  ALLUSERSPROFILE=C:Documents and SettingsAll Users
  APPDATA=C:Documents and SettingsautomatedqaApplication Data
  COMMONPROGRAMFILES=C:Program FilesCommon Files
  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;
  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;
  PROCESSOR_IDENTIFIER=x86 Family 6 Model 26 Stepping 5, GenuineIntel
  PROGRAMFILES=C:Program Files
  PWD=c:uildbot	runk-continuousuild
  USERPROFILE=C:Documents and Settingsautomatedqa
  VS100COMNTOOLS=C:Program FilesMicrosoft Visual Studio 10.0Common7Tools
  VS90COMNTOOLS=C:Program FilesMicrosoft Visual Studio 9.0Common7Tools
 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. '

Change History (9)

comment:1 Changed 10 years ago by dustin

  • Description modified (diff)
  • Keywords windows added
  • Milestone changed from undecided to 0.8.+

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by dustin

  • Cc callek added

Callek, any suggestions here?

comment:4 Changed 9 years ago by philippem

It is buildbot that is setting the paths, in 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.

comment:5 Changed 9 years ago by 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 was created based on one particular VS-installed machine.

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by 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.

comment:8 Changed 8 years ago by tom.prince

  • Priority changed from major to patches-accepted

comment:9 Changed 7 years ago by dustin

  • Milestone changed from 0.8.+ to 0.9.+

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.