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

[BRM]

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

>> Ultimately the user should not care so long as the build gets done
>> correctly, so the default will most likely be utilizes 90+% of the time.
>> 
>> >>  I also agree with Ben about not relying too much on env variables,
>> >>  I'd rather pick the installdir from the registry.
>> > Why? It's pretty standard way to retrieve install directory from
>> > scripts. 
>> 
>> Don't rely on environment variables for finding the appropriate BAT
>> file. Use the registry.  It's cleaner, simpler, and more reliable.
>
>It's probably undocumented too =) As environment variable. At the same
>time there are a LOT of questions in MS Social how to find MSVC, and every
>answer states VSxxCOMNTOOLS environment variable as base. It's configured
>by visual studio itself. So no actions from user are required.


Documented or not, I've found it very reliable.
See the bug report (http://trac.buildbot.net/ticket/2108) for the registry keys I know about, and the ones I reference do not use environment variables either.
I've also noticed there are a lot of things that are setup via the environment variables that are matched in the registry without using environment variables.


>> We're talking around a different issue here.  The real issue in the
>> above is: do we want to have buildBot setup and teardown the vs
>> environment?  The question is: is that really necessary?
>> 
>> Now, to setup the environment it is best to rely on the BAT files
>> provided by MS with each version of VS.  To tear down, you have to UNSET
>> about 10 environment variables.  This can be done cleanly (I've done it
>> in my own scripting environment); but you have to do research for every
>> version of VS that is supported.  (I have information for VS6, 2003, and
>> 2008 at present.)
>
>You are talking about launching "buildslave" from VC command prompt so
>it'll inherit environment?
>
>There is no tear down in patched code I've. It just launches process that
>setups own environment and dies after build. So nothing to restore.


That's what I would have expected it to do.

Is that not what mainline buildbot does?


>> However, I doubt that is necessary for buildBot to do unless two builds
>> running on the same slave share the same environment variables.  If they
>> do, then the better solution would be to try to separate those two
>> environments so that they don't interfere with each other.
>
>It's necessary at least for me.. Since we're running 32 and 64 bit builds
>on same slave.. Also it may be pretty good idea to run two different VS
>builds on same slave.


I agree it's necessary that two builds on the same build slave not interfere with each other.

I take it the difference to VS for the 32-bit and 64-bit is a command-line setting in the project, correct?
In which case, you're not talking to separate installations of the same version of VS.


>> However, finding VCVARSALL/VCVARS32 should not rely on environment
>> variables or hard coded paths.  The best way to locate the installation
>> is via the registry.
>
>Why not environment if it's configured by VS installer. Also all current
>VS versions relays on this environment because IIRC some registry values
>contains %VS90COMNTOOLS%-like macro.


Depends which ones you use. The ones I referenced don't.
So it's not necessary to have to supplement the what is retrieved from the registry with values from the command-line environment.
Otherwise I'd fully agree that it would be better to just use the environment variables.

Ben