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

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
> >>>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.

Sure.

> > 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:

call vcvars.bat
cl.exe ...

where vcvars.bat calls vsvars.bat, which sets up the PATH, INCLUDE and LIB 
variables. With my patch, this becomes:

set PATH=...
cl.exe

so there aren't 3 levels of indirection (run.bat -> vcvars.bat -> 
vsvars.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 
>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?

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
>vcvars.bat.

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.

- Reece