From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-11-08 15:51:37
On Wednesday 08 November 2006 21:42, Rene Rivera wrote:
> Vladimir Prus wrote:
> > Rene,
> > 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.
That sounds like bigger problem that it really was. In practice, you don't
install new versions of compilers every day, so saying
python test_all.py msvc-8.0
is quite a reasonable way to test things.
> > For example, prebuilt.py fails. That test uses:
> > t.expand_toolset("ext/Jamfile")
> > 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',
> 'ext/bin/msvc-8.0/debug/a.dll.rsp', 'ext/bin/msvc-8.0/debug/a.exp',
> 'ext/bin/msvc-8.0/debug/a.lib', 'ext/bin/msvc-8.0/debug/a.obj',
> 'ext/bin/msvc-8.0/debug/a.obj.rsp', 'ext/bin/msvc-8.0/debug/a.pdb',
> 'ext/bin/msvc-8.0/release/a.dll.rsp', 'ext/bin/msvc-8.0/release/a.exp',
> 'ext/bin/msvc-8.0/release/a.lib', 'ext/bin/msvc-8.0/release/a.obj',
> Removed files : 
> Modified files: 
> Touched files : 
> STDOUT ============
> error: Unable to find file or target named
> error: 'bin/msvc/debug/a.lib'
> error: referred from project at
> error: 'ext'
> STDERR ============
> END ===============
> > 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
Isn't this just a matter of saying "specify toolset with version" in docs?
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