[Buildbot-devel] BuildBot & Visual Studios....

[BRM]

>From: Dmitry Nezhevenko <dion at dion.org.ua>

>To: buildbot-devel at lists.sourceforge.net
>Sent: Wednesday, September 21, 2011 7:37 AM
>Subject: Re: [Buildbot-devel] BuildBot & Visual Studios....
>
>On Tue, Sep 20, 2011 at 09:23:19AM -0700, BRM wrote:
>> Just wanted to bring up a bug for discussion. I'm not familiar enough with Buildbot's protocols/etc to tackle it myself at present, and any support for InstallShield will likely need to follow the same kind of route.
>> 
>> http://trac.buildbot.net/ticket/2108
>> 
>> I finally got to the point of testing a build, and it failed because
>> Buildbot had the incorrect path for VisualStudios, namely because the
>> path was hard coded. Microsoft provides the required paths in some nice
>> registry keys that we can access via Python - via either the
>> _winreg/winreg built-in modules, or via PyWin32's win32api module. I
>> reported the paths I know about in the bug.
>
>> For now, I can probably work around it using the "installdir" parameter.
>> However, it would be very helpful for me (and likely others) to use the
>> registry method in the bug report.
>
>There is a bit easier way to do this. I'm using own version of compile
>step. It basically gets MSVC path from environment. It works pretty well
>here.
>
>Also it uses vcbuild instead of deprecated devenv.com. Here is a link to
>actual code:
>
>http://dion.org.ua/uploads/2011/09/buildbot_compile.py


If I understand your code and what you said, then you are using an environment variable to support which one. But the, you can only use one version of VS, right?
If so, that is problematic - I need 3 different versions myself.

Support for InstallShield is really necessary in a similar manner; and I'd even advocate that other tools - e.g. SVN - should be too (though for SVN that relies on using the CollabNet installer to get the registry settings, so it's not quite reliable in that aspect).


>But there is third way called "msbuild". All of this looks too ugly. I
>really don't know, which one is the best.
I think MS is moving towards using msbuild. It's not really all that different from using devenv, and pretty simple via the command-line if I recall. Here's the docs: http://msdn.microsoft.com/en-us/library/ms164311.aspx



----- Original Message -----
> From: Benoît Allard <benoit at aeteurope.nl>
>>  For now, I can probably work around it using the "installdir" 
> parameter.
>>  However, it would be very helpful for me (and likely others) to use the
>>  registry method in the bug report.
> 
> The main trouble over there is that you need to run some actions on the slave to 
> know the right path. This is not something the current architecture easily allow 
> you to do. The slaves have a set of capabilities, namely commands, and can't 
> do anything for the master beside that.
> 
> For this to be possible, you need:
> 
> 1. Add a command on the slave like "QueryRegistryValue" or such
> 2. Invoke that command from the vstudio steps (which runs on the master)
> 3. use the return value to update the settings sent during the actual
>    invocation of devenv.
> 
> Nothing impossible, patch welcomes ;)

Where do I need to go to modify the master-slave protocol to add the QueryRegistry functionality?

I'd propose:
- Add the query registry functionality to the protocol
- Have the vstudio.py query the slave and set the value accordingly.

I looked at the vstudio.py yesterday a bit while trying to figure out what I needed to do to get things working.
So, I'd see this as being done vstudio.py's VisualStudio object, probably in SetupEnvironment or setupinstalldir.

Would it be correct to say that a builder's instance only communicates with one slave? (So if you have multiple slaves doing the same build, then each would have their own associated instance of a builder in the master.)

I'll see what I can conjure up.

Ben