From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-05 14:06:13
David Abrahams wrote:
>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?
I was referring to the trick to invoke vcvars.bat before cl.exe.
>Do you realize that bjam creates a batch file and calls cmd unless you
>go out of your way to avoid it?
I understand this, but what we currently have is:
execute( "cmd.exe run.bat" );
where run.bat invokes:
where vcvars.bat calls vsvars.bat, which sets up the PATH, INCLUDE and LIB
variables. With my patch, this becomes:
so there aren't 3 levels of indirection (run.bat -> vcvars.bat ->
> > * 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
> > using msvc : 8.0 ;
> > and:
> > $ bjam release msvc-8.0 architecture=ia64
>That seems possible whether or not we're calling vcvars.bat, no?
Yes. However in my VS.NET beta 2 install, I only have vcvars.bat,
x86_amd64.bat, x86_ia64 and x86_arm.bat even though I have all the other
cross-compilers installed (arm, mips, sh and cex86). Also, checking the
x86_arm file it specifies the wrong directory for the lib file (vc/cw/lib)
and does not add the vc/atlmfc/... paths.
Granted, I could fix this by writing my own vcvars.bat, however, why should
I do that when I have the settings configured by my build system?
> > 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
Yeah. Maybe if you don't supply a vcvars.bat, instead of defaulting to
vcvars.bat it sets up the configuration as in the patch. However, if you do,
it does the existing behaviour.
> > * 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.
It may be me :). As I said, I need to run tests and get the timing data to
make any definite response.
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