>BTW, I had to remove the line
> <runtime-link>static
>from the serialization/test/Jamfile to get the serializiation
>regression tests to link on my Linux machine. With g++ this was
> adding a -static which was apparently making it not find libstd++.
Hmm - no other gcc setup required this. Might this indicate that a tweak is
necessary somewhere in config gcc/linux/mandrake/? Combination>
This brings up an enduring mystery to me. Here is the key part of the
jamfile from the build directory.
lib boost_serialization
: ## sources ##
../src/$(SOURCES).cpp
: ## requirements ##
<msvc><*><include>$(SPIRIT_ROOT)
<borland><*><include>$(SPIRIT_ROOT)
<borland-5.5.1><*><include>$(SPIRIT_ROOT)
<borland-5.6.4><*><include>$(SPIRIT_ROOT)
<sysinclude>$(BOOST_ROOT)
<borland><*><cxxflags>"-w-8080 -w-8071 -w-8057"
<msvc><*><cxxflags>-Gy
<vc7><*><cxxflags>-Gy
<vc7.1><*><cxxflags>-Gy
<define>BOOST_TEST_NO_AUTO_LINK=1
: ## default-build
<runtime-link>static <threading>single/multi
;
I set default-build based on - I don't remember. I did horse around with it
to get it in sync with with my MSVC IDE settings so I could inter-operate
with MSVC IDE and bjam. This was very helpful for development. However, I
really don't know that the build should even specify a default. Is this a
default or does this override some other default build setting. That is if
I just leave it out do I get no build at all or what. I did spend a little
time perusing the included JAM files - but that's a mind bending exercise
for "the rest of us". Would think I would just leave off the default build
and let the upper level test/build build what it wants. Of course then is a
silently morphing side-effect which I'm generally against.
I don't believe the current test results displayed reflect the true current
state of the serialization system.
My results are:
a) I've tested borland 5.5.1, 5.60, VC 6.0 with good results. Test results
show failure for these platforms because the test setup doesn't make spirit
1.61 available which is a requirement for these platforms.
b) I've tested VC 7.1 and gcc 3.3 under cygwin. VC 7.1 Is 100 % passing.
Gcc under cygwin passes all tests except those requiring wide char i/o which
is not supported on this platform. The table generates "fail" for these
tests but that's not really accurate.
c) Christophe has 100% passing on linux with gcc 3.4.1 . (gcc 3.4.0 had a
show stopping issue which was easiest to address by upgrading.
Unknown results:
a) gcc 3.3.? on linux - I would expect 100% here. No results available
pending the disk space issue.
b) a) gcc 3.3.? on linux/mandrake - see above.
Problems:
a) Macos/Darwin.
i) lots of tests passing
ii) some confusion as to whether wide char i/o is supported here
iii) a couple of run failures that need to be looked at with a debugger.
Any volunteer?
b) Comeau - a compiler issue with non-intrusive serialization. Set aside
for now.
c) IBM C++ - a comple issue re-interator traits. Since these tests are run
very infrequently, its almost hopeless to address by trial and error.
d) CWPro - compile issue - size_t not recognized? Clearly this needs an
expert.
e) Intel 7.1 - I had Intel 8.0 passing 100% before my eval license exprired.
I can't fix this from my own machine. Needs an expert - or my own copy of
intel 7.1. I'm sure this is easily fixable given that msvc 6.0 works pretty
well.
f) HP - very bizarre compilation error. I don't know but I suspect this
would be the tip of an ice berg. Needs an expert.
So - there you have it - In my view test results of the serialization
library are not out of line from those of other platforms. Also the fact
that there are more combinations tested perhaps brings to fore more issues
than with other libraries.
I would suggest we keep flogging away at it until just before the branch is
made. That would be a good time to make a final decision.
Robert Ramey
