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:
>>> we have six merge requests open. I've reviewed
>> I just finished a better alternative. It generates batch file
>> replacements in temporary directory (obtained by reading TEMP
>> environment variable).
>> 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
return a ;
return b ;
is the same as
return a ;
return b ;
Thanks for spotting this. I have updated the branch.
> 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
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
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