Re: [Boost-build] merge request

Subject: Re: [Boost-build] merge request
From: Jürgen Hunold (jhunold_at_[hidden])
Date: 2014-06-22 09:46:21

Am Samstag, 21. Juni 2014, 19:59:17 schrieb Juraj Ivančić:
> On 21.6.2014. 14:43, Jürgen Hunold wrote:

> > Yes, finally. This creates the scripts in the TEMP directory, but still
> > calls vcvars.bat before the compiler invocation. Is the patch complete or
> > am I missing something?
> 
> You are missing less than I have. I once again fell into the trap of
> thinking that

> Thanks for spotting this. I have updated the branch.

Yes, "return" does not return. One design failure of the jam language 
violating the rule of least surprise...

> > Notes:
> > I was surprised that scripts for *all* compilers (x86, x64, arm...) are
> > created. Can this be detected?
> 
> Well, not really *all* compilers. Just any plausible combination for
> compilers which are configured (via 'using' directive). Some
> combinations do not make sense, and those will not generate a batch file.

I get:

jam_msvc_12.0_vcvarsall_x86.cmd
jam_msvc_12.0_vcvarsall_x86_amd64.cmd
jam_msvc_12.0_vcvarsall_x86_arm.cmd

which are all toolset installed. And of course batch files for all other msvc 
versions installed.

Personally, I don't like the "jam_" prefix as this might be confused with the 
original jam. Can you change this to "b2_", please?

> As far as detecting which of these generated batch files are really
> needed by build - this goes into the same problem domain as determining
> the best place where to put replacement scripts. Currently, toolset gets
> initialized before any user project files (i.e. Jamroot). So, unless we
> add some kind of 'project initialized' hook to toolset modules, this is
> the best I can think of. And that hook feels like opening another can of
> worms.

Yes. At least not now.

> With this patch, each MSVC toolset initialization will generate at most
> 4 batch files, and all of those make sense. I believe this to be a small
> price to pay, opposed to calling original MSVC scripts for every action.

It would be nice to have this documented. As this a real improvement as well 
as a behaviour change.

> > Is it possible to detect if the compiler is already setup (e.g. via visual
> > studio command prompt or manually) and skip calling the setup script?
> 
> This is a different problem all together, and I don't think that's
> realistic at this point. How to detect that user wanted x64 build while
> being in a x86 prompt? What if some targets are x86, and some are x64?
> What to do when user passes address-model=32,64?
> 
> While I am sympathetic to the requirements you just made, this fix
> merely tries to avoid calling an expensive batch file with every build
> action.

Yes, of course. I was musing about the ML complaints/requests  that b2 should 
honour visual commandline prompts. If this had been easy, it would have been 
nice to have. But the speed improvements are more important.

If you can add some lines to the docs or provide a text snippet to paste in 
and change the prefix,  I'm for merging this in.

Yours,

Jürgen
-- 
* Dipl.-Math. Jürgen Hunold  ! 
* voice: ++49 4257 300       ! Fährstraße 1
* fax  : ++49 4257 300       ! 31609 Balge/Sebbenhausen
* jhunold_at_gmx.eu             ! Germany