From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-11-08 13:42:58
Vladimir Prus wrote:
> on CVS HEAD I observe a few test failures that might be related to your 'glob
> for toolset name' patch.
Well they are not really related to that patch. They just never passed
unless the toolset one passes in matches exactly the toolset name used.
Which meant that it basically never matched when using msvc. I.e. it
would never match when using an autodetected tool.
> For example, prebuilt.py fails. That test uses:
> to change $toolset in Jamfile to the actual toolchain name, so that it can
> refer to rebuild binaries. Apparently, $toolset gets replaced with
> just 'gcc', while the binary path has gcc-4.0.3, so the test fails.
Or with 'msvc' in my case:
prebuilt : "['bjam',
'-d0', '--quiet', 'debug', 'release', 'msvc']" returned 1
-------- all changes caused by last build command ----------
Added files : ['ext/bin/msvc-8.0/debug/a.dll',
Removed files : 
Modified files: 
Touched files : 
error: Unable to find file or target named
error: referred from project at
> Any ideas how to handle this?
What comes to mind is changing the test so that after building what are
supposed to be the prebuilt targets to copy/stage them to a known
location. Then use that in the prebuilt targets. I.e. making the test
independent of the toolset used.
> Maybe we should, instead of globbing, detect the
> used version of gcc early in BoostBuild.py and then just it it?
I don't think so. What happens for other toolsets? Relying on the
toolset names is just terribly fragile and user hostile. If we want
people with access to uncommon toolsets, and platforms, to use this for
testing we'd better make it as easy as possible to run the regression tests.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
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