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
>> 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 ;
> $ 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
> * 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk