[Buildbot-devel] [win32] service not quite working with VS2008, env problem

Stephen Davis buildbot at soundgeek.org
Fri Nov 28 22:44:18 UTC 2008


On Nov 27, 2008, at 1:31 AM, Marcus Lindblom wrote:

> Stephen Davis wrote:
>> Hi all,
>>
>> I have a buildbot service set up with an installation of VS2008 but,
>> since VS2008 no longer installs its environment variables into every
>> user's PATH, etc., the builds fail b/c the environment is not  
>> properly
>> set up.  I slogged through the stuff that happens when you execute  
>> the
>> VS2008-specific cmd shell and it's not a simple matter of adding a  
>> few
>> entries to the buildbot user's environment.  It executes a series
>> of .bat files.
>>
>> Since each build step invocation gets its own shell (I assume),  
>> what's
>> the easiest way to get the right environment variables set up?
>
> What I've done in similar situations is to create a batch-file called
> wrap.cmd containing:
>
> @echo off
> call %VS9COMNTOOLS%\vsvars32.bat
> SET FOO=bar
> cmd /c %*
> exit /b %ERRORLEVEL%
>
> Then write my own ShellCommand() wrapper that just runs
> 'cmd /c call wrap.cmd' + args.
>
> (The 'cmd /c call' ensures correct error level propagation from batch
> files.)
>
>> Can you specify a .bat file that runs when the user logs in (a
>> la .login on unix)?
>
> Not so that all subsequently started processes get the same env,  
> AFAIK.
>
>> Could I change the path to PythonService.exe in the service's  
>> registry
>> entry to point to a .bat file that sets up the environment and then
>> runs PythonService.exe?
>
> That might work, but I haven't tried it. You can't specify a batch  
> file
> as a service (nor a regular exe, it needs to export some
> service-specific functions for start/stop/pause), so you'd have to go
> through a wrapper executable, such as srvany.exe (available in the
> Windows resource kit).
>
> Using that, to start cmd.exe, to run your wrapper then run buildbot.py
> might work.
>
>> I am not a Windows guy at all so I'm floundering here.
>
> The ShellCommand is the simplest way.

That's a good idea.  I already have a custom "compile" class that  
knows how to parse VisualStudio build output to separate the warnings/ 
errors from stdout so I'll just put it in there.

thanks,
stephen




More information about the devel mailing list