Re: [boost] build and regression test problems

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
default
>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:
>
>run_tests type_traits
>
>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
case.

>This
>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
sitting
>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:
>
>$ bjam
>//cygdrive/c/data/boost/develop/boost/libs/regex/base.jam: Permission
denied
>
>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
occur.

>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
it
>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