[opensource-dev] autobuild setting UNATTENDED questions
Brad Kittenbrink (Brad Linden)
brad at lindenlab.com
Fri Mar 25 15:20:41 PDT 2011
On Fri, Mar 25, 2011 at 11:04 AM, Ima Mechanique <
ima.mechanique at blueyonder.co.uk> wrote:
> I'm trying to find out more information about this setting and the piece
> of code it controls. Non Windows devs can switch off now as it only
> affects them by causing a warning about it not being used.
> 1) Is it still needed. All configurations, even the TC ones, have it
> defaulting to off. This causes problems for VCE devs as the vstools
> program controlled by it causes an error for them.
> It's purpose appears to be to set the working directory for running the
> .exe. However, the .exe runs just fine without it being set.
The working directory setting may no longer be necessary after this
If so, that's good news. However, I believe that we also use it for setting
the default configuration to RelWithDebInfo, which we still require.
2) If it really is necessary, could we change the program run (vstools)
> to something more compatible with all VC versions. Now the project files
> are XML based, it should be possible to do this as part of autobuild
The source for vstool is
(Yes, it's C#, don't ask me...) If there's a way to make it compatible with
VCExpress I'd love to do so, but to my knowledge VCExpress doesn't expose
the macro apis that this relies upon, so it's likely impossible to directly
extend that script to this case. I don't think it makes sense to build
support for tweaking these xml files into autobuild, as autobuild is
intended to be as fully decoupled from the details of individual build
systems as possible.
An alternative is getting this kind of feature built into cmake. For
example, this issue <http://public.kitware.com/Bug/view.php?id=8884> is a
feature request for making another kind of modification to the
*.vcproj.*.user configuration file where these settings are saved.
In the mean time, I would definitely recommend updating the VCExpress
configurations to pass -DUNATTENDED:BOOL=ON on the command line until we
find a better solution for this. We used to do a lot more with the
--unattended argument to develop.py, but I think this is all that remains of
that cruft, so it's safe to use for this purpose.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opensource-dev