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