Rene Rivera wrote:
Robert Ramey wrote:
Actually this kind of approach has interested me for some time.
[cut]
That's not what I meant... What I meant is that *you* can change the serialization *code* to disable the serialization library features when they are not available/usable.
But they would still show up as failures in the test system. The test results would look the same. That's why I am attracted to idea of running only those tests which actually test something expected to work. This requires some sort of feedback from config.h to the test system which is why I was thinking of a small test program which would fail if the system can't be built and make the other tests dependent on that test.
Note that these tests pass with V1 so the issue isn't with the serialization library itself, its just that that is where some "corner cases" show up.
BBv1 had kludges to suppress/work-around the errors in the serialization library.
I am not aware of any such errors in the serialization libary. I don't consider it an error that some compilers cannot support conforming code - and I don't think boost does either. I'm not aware that BBv1 had/has any such kludges. V1 jamfiles had some "kludges" to permit testing on these platforms. These reflect weakness in V1 which I'm hoping have been addressed in V2. For me the jury is still out on this as I haven't really re-visited Jamfiles with V2.
Depending on the build system for portable software is never the best solution.
I'm depending on the build system for building and testing the library to the extent that it is supported by the compiler and environment. I believe that is what the build/test system is for. In the case in question, the serialization library depends upon spirit to parse xml input. The boost version of spirit - 1.8 does not support these compilers. So the serialization library doesn't either. The developer's of spirit have kept 1.6 around for such situations the users of the serialization libary with these compilers have the option to use spirit 1.6 or not use xml archives. These are all legitimate options. Ideally the build/test system would support the options preferred by the user. Note that the whole issue is repeated with regard to wide char i/o. It doesn't really show up now that it seems that (almost?) all platforms being tested support wide char i/o. So to me, there are couple of disjoint issues. a) getting 1.34 out in the "best" way. b) how should libraries which support different levels of functionality be handled with V2? I really think this should be handled in the HEAD branch. Robert Ramey