Opened 3 years ago

Last modified 3 months ago

#2108 new enhancement

BuildBot uses incorrect method for default location of Visual Studios

Reported by: TemporalBeing Owned by:
Priority: minor Milestone: 0.9.+
Version: 0.8.5 Keywords: windows
Cc: rutsky.vladimir@…

Description

Buildbot presently uses a hard coded value for the default location of Visual Studios. This means that the user would need to use the 'installdir' parameter to the VS builders whenever they (i) install to a different drive, (ii) install to a different directory. This could be very common, especially on computers that have multiple OSes installed.

Fortunately, Microsoft did provide a nice way around this issue - look to the Windows Registry. Personally I have done this for scripting for VS6, VS2003, and VS2008 in which I can report the following registry keys work very well:

Visual Studios 6 HKLMSoftwareMicrosoftVisualStudio6.0SetupMicrosoft Visual C++ProductDir?

Visual Studios 7.1 (aka VS2003) HKLMSoftwareMicrosoftVisualStudio7.1SetupVSVS7CommonBinDir

Visual Studios 9 (aka VS2008) HKLMSoftwareMicrosoftVisualStudio9.0SetupVSVS7CommonBinDir

We should be able to use the pattern above (for VS7/9) for a starting point for later versions at the very least, using the following pattern:

HKLMSoftwareMicrosoftVisualStudios<Version>SetupVSVS7CommonBinDir

Doing this provides two major benefits:

1) Default is now the default of the installed version of Visual Studios. So 'installdir' is only useful in very weird installations (such as having custom built installations or multiple installations of the same version on the same system, etc.)

2) Buildbot can now provide a check to see if the requested version of VS is installed prior to attempting the build, and provide a good error message if it is not (something like VS2008 is not installed on the buildSlave) as opposed to simply reporting that the build program (e.g. devenv.com or msbuild) was not found in the path.

The only potential problem is the client-server approach of Buildbot since the registry would need to be read on the build slave instead of the build master. This could provide some challenges to implementation.

PyWin32 provides support for accessing the registry via the the win32api module, which seems to use the same interfaces as VC++ code so it should be pretty straight forward. Python also natively supports the Windows Registry via the _winreg (2.x) and winreg (3.x) modules.

http://docs.python.org/library/_winreg.html

http://docs.activestate.com/activepython/2.7/pywin32/win32api.html

Change History (5)

comment:1 Changed 3 years ago by dustin

  • Keywords windows added
  • Milestone changed from undecided to 0.8.+

I wouldn't be opposed to adding a read_registry slave command, and using that in the vstudio class. Do you want to give that a shot?

comment:2 Changed 3 years ago by dustin

There's a good discussion of this issue on the mailing list now:

http://article.gmane.org/gmane.comp.python.buildbot.devel/7736

comment:3 Changed 3 years ago by TemporalBeing

Yes I'll give it a shot.

Already have something partially done that I need to test for the registry access. That'll be one patch. Then I'll try to update the VS stuff to use it as another patch.

comment:4 Changed 15 months ago by rutsky

  • Cc rutsky.vladimir@… added

comment:5 Changed 3 months ago by dustin

  • Milestone changed from 0.8.+ to 0.9.+

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.