Re: [boost] build and regression test problems

From: John Maddock (john_at_[hidden])
Date: 2003-09-24 05:39:57

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

Yes, everything still works OK except for the compiler_status step:

#
# STEP 6:
# create the html table:
#
uname=`uname`
echo generating html tables:
$compiler_status 'c:\data\boost\develop\boost' cs-$uname.html
cs-$uname-links.html
if test $? != 0 ; then
    echo "Failed HTML result table generation."
    exit 256
fi

In this case $compiler_status is just the path to the (vc7.1 built)
executable, and my code is ripped right out of the sample script.

> 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 ;-)

OK that's good to know.

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

I think cygwin uses // as a network path prefix.

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

Well it's no use as it is, I'm sure that at one stage the source path was
added automatically (some compilers search this path anyway, but not all).

Thanks,

John