From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2003-09-05 05:20:28
First of all, I also had the "out of range" error which made my nightly
regression tests fail. I tried to analyse the problem but failed to find
it. However the IBM of last night apparantly worked (see
boost.sourceforge.net/regression-logs). My compilation on IRIX fails for
two days in a row however.
> >One thing I noticed is that this documentation indicates
> setting a >BOOST_ROOT environment variable, whilst
> run_tests.sh uses boost_root, I >was under the impression
> that case mattered - or is this irrelevant as >boost_root is
> always passed into the executables on the command line
> >rather than automatically referred to?
> I don't know the answer to that. Someone familiar with
> running under Unix
> needs to answer.
Indeed case does matter. 'boost_root' however is defined arount line
number 10 in the run_tests.sh. Now I start to wonder, would it be better
to just rely on BOOST_ROOT (the env.var.) instead of defining boost_root
and providing this var to the command line of the 'compiler_status' exe
? Beman ?
> >I retried the processing of the regression test results
> using the >run_tests.sh script and got exactly the same
> result from >'compiler_status', namely >
> >*** Error: std::runtime_error: boost::filesystem::directory_iterator
> >No such file or directory
> >BOOST_ROOT (and boost_root in the script) were set to
> >so I believe it is the processing program that is adding
> the spurious >'0_2' to the path.
> I would do several things if that happened here:
> (1) run only on a single test (I usually use config_info). That makes
> testing simpler and quicker.
I tried to do that but. On Sun this works fine for instance.
On IBM however, I get
/home/tk/boost_regression/boost/status> bjam config_info
...found 35 targets...
...updating 1 target...
mkdir: 0635-358 Cannont create ...
...: Do not specify an existing file.
This is really weird. I have not set ALL_LOCATE_TARGET. Anybody any idea
what could be going wrong ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk