From: Rene Rivera (grafik.list_at_[hidden])
Date: 2003-09-23 12:04:24
[2003-09-23] John Maddock wrote:
>I'm experiencing a number of newly occurring build related problems:
>1) The regression tests: the compiler_status program is failing to find the
>regression test output files. The problem is that at some point the
>build location has shifted from ./bin to something like
>$(TOP)/bin/boost/$(SUBDIR). This looks like a reasonable change but
>compiler_status is still looking in ./bin.
By "./bin" you mean "$(TOP)/$(SUBDIR)/bin" ?? AFAICT compiler_status never
looked specifically in "./bin", but it does look in locate-root/subdir/bin
as a compatability fallback (so that it still works with 1.30.* tests).
>Note that my use of
>compiler_status is slightly unusual in that I have a shell script (under
>cygwin) that lets me do things like:
>and the script will cd into libs/type_traits/test and run the tests from
>there, and then generate a set of type_traits specific html tables.
Well doing a "bjam test" in libs/type_traits/test works, and correctly puts
it's results in "locate-root/bin/boost/libs/type_traits/test/...". But I'd
have to look at your scripts to see how you generate the limited HTML
tables. To hopefully modify compiler_status+process_jam_log to work in that
>has now stopped working since the build system change. If I've understood
>this correctly, then I suspect that some of our regression testers are
>actually generating tables for old "stale" results that happen to be
>on their hard drive rather than the new "fresh" results that been silently
>moved to the new directory structure.
As Martin mentioned, if you run the test from boost-root/status it will use
the new results.. Without the need to clean out anything. But cleaning out
does save you disk space ;-)
>2) Probably cygwin specific: regex is failing to build with:
>Note the leading "//" this is the cause of the problem here (it works fine
>on Linux though strangely enough).
Well the not understanding "//" as equivalent to "/" is a cygwin shell
bug/incompatability with real *nix. But I've never figured out where we
generate those extra "/"'s in Boost.Build.. That's not the only place they
>3) Broken stage rule: stage rule lib name mangling is no longer working for
>the regex lib build - see libs/regex/build/Jamfile. Probably effects
>signals lib and Rene's new install code as well.
OK, how is it no longer working? If doesn't work anymore I can see how it
would affect signals lib as it's a copy of the same name mangling code. The
install code uses it's own name mangling, the new and hopefully to be
standard mangling, so it should not be affected.
>4) Broken include path: I'm seeing the lib build include path set
>as -I"..\..\bin\boost\libs\regex\build" which is nonsense, I presume that
>should be adding the source code path to the includes instead?
I'm not sure what that should be. It's a rather strange one in that in the
build code it's explicitly added to be relative to the build location not
the source location. So in a sense it's correct, but I don't see what the
use for it is and I just kept it as it was in the changes. Perhaps Dave
knwos what it's for?
>In hopes of fixes,
Aren't we all ;-]
-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk