Re: [Boost-build] merge request

Subject: Re: [Boost-build] merge request
From: Juraj Ivanèiæ (juraj.ivancic_at_[hidden])
Date: 2014-06-21 13:59:17

On 21.6.2014. 14:43, Jürgen Hunold wrote:
> Hi Juraj,
>
> Am Dienstag, 17. Juni 2014, 12:44:25 schrieb Juraj Ivanèiæ:
>> On 16.6.2014. 11:57, Jürgen Hunold wrote:
>>> Hi,
>>>
>>> we have six merge requests open. I've reviewed
>>>
>>> https://github.com/boostorg/build/pull/6
>>
>> I just finished a better alternative. It generates batch file
>> replacements in temporary directory (obtained by reading TEMP
>> environment variable).
>>
>> https://github.com/jivancic/build/tree/slow_msvc_setup_scripts_2
>>
>> Could you try that one?
>
> 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

if $(x)
{
  return a ;
}
return b ;

is the same as

if $(x)
{
     return a ;
}
else
{
     return b ;
}

Thanks for spotting this. I have updated the branch.

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

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.

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.

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