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

[Dmitry Nezhevenko]

On Fri, Sep 23, 2011 at 07:18:12AM -0700, BRM wrote:
> factory.addStep(VS2003MsEnv(projectfile='MyProject.vcproj', config='Release', mode='rebuild'))
> factory.addStep(VS2003DevEnv(projectfile='MyProject.vcproj', config='Release', mode='rebuild'))
> factory.addStep(VS2003VCBuild(projectfile='MyProject.vcproj', config='Release', mode='rebuild'))
> factory.addStep(VS2003MSBuild(projectfile='MyProject.vcproj', config='Release', mode='rebuild'))

> I think the second makes more sense. It also maintains compatibility, and we can set a sane default.
> It also makes it easier to report when a certain versions of VS stop providing one tool or update to add another.

Agreed here.

> 
> 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.

> 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.

> 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.

> 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.

-- 
WBR, Dmitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://buildbot.net/pipermail/devel/attachments/20110923/5b422c1f/attachment.bin>