Re: [BBv2] [msvc] Remove call to vcvars.bat

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-05 09:03:47

Reece Dunn <msclrhd_at_[hidden]> writes:

> David Abrahams wrote:
>> Reece Dunn <msclrhd_at_[hidden]> writes:
>> 
>>>The attached patch is the first attempt at removing the need to call 
>>>vcvars.bat.
>> 
>> Why is that a good thing?

For the record, I don't have a strong opinion about what we should be
doing; I just want to make sure that eliminating vcvars.bat is not
being treated as an end in itself, and that it actually gets us the
benefits we're after.

> This is a good thing because:
>
> * We remove the need to invoke cmd / call a batch file, which would 
> (should) give a performance increase as we are no longer executing 
> vcvars.bat each time the compiler or linker is invoked.

How is the environment going to get set up if cmd isn't being called?
Do you realize that bjam creates a batch file and calls cmd unless you
go out of your way to avoid it?

> * The user doesn't need to specify the vcvars.bat for 
> msvc-8.0/x86-amd64 as this is a known configuration, so the user just says:
>
> using msvc : 8.0 ;
>
> and:
>
> $ bjam release msvc-8.0 architecture=ia64

That seems possible whether or not we're calling vcvars.bat, no?

> This is a bad thing because:
>
> * The user can no longer pass a custom vcvars.bat to set up, for 
> example, embedded VC++. Note, though, that the setup should be such that 
> these configurations should work - maybe we need to pass the path, 
> include and library lists instead of the setup/vcvars, or use a default 
> generic setup configuration.

Agreed, so it seems like it should be possible to keep calls to
vcvars.bat.

> * How do we tell bjam that embedded VC++ 4.0 is VC 6.0 for arm/sh?

Make the necessary changes to the toolset.

> * There is currently a slight load-time delay that I believe is due to 
> the memory allocation issues that Rene has mentioned. When this is 
> improved, this load-time should decrease. However, there should be a 
> slight increase in each compile/link call that would even out the 
> load-time delay on a large build.

I don't understand, but maybe it's not important.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com