On 10/29/2013 10:36 AM, Steven Watanabe wrote:
On 10/29/2013 10:08 AM, Eric Niebler wrote:
On 10/29/2013 9:55 AM, Steven Watanabe wrote:
As a curiosity, I'll note that the project-root.jam created by "bootstrap.bat gcc" contains a "using msvc ;" and not "using gcc ;", which seems wrong to me.
bootstrap.bat sets msvc unconditionally. The language for batch scripts is really horrible, so working this out correctly is likely to be very painful.
It is a horrible language that I know quite well. If you write the pseudo-code, I can translate it into command script for you.
In tools/v2/build/engine/build.bat:
if --guess-toolset in $argv call :Guess_Toolset return $BOOST_JAM_TOOLSET
Also, make sure that local variables don't escape. I don't know how to pass the return value through setlocal.
The hackish way to do this is to write the "return value" into a file, and then read it back in.
(I just noticed this in bootstrap.bat: REM Ideally, we should obtain the toolset that build.bat has REM guessed. However, it uses setlocal at the start and does not REM export BOOST_JAM_TOOLSET, and I don't know how to do that REM properly. Default to msvc for now.)
in bootstrap.bat:
TOOLSET = find argument --with-toolset=xxx
Doable.
if not $TOOLSET set TOOLSET=`tools/build/v2/engine/build.bat --guess-toolset`
This doesn't seem right. build.bat takes a toolset as an optional argument. If the user specified --with-toolset=xxx to bootstrap.bat, then shouldn't xxx get passed as the toolset argument to build.bat? -- Eric Niebler Boost.org http://www.boost.org