[1.33] recent check-ins break date-time serialization tests
I didn't look at the check-in logs, but in the last 24-48 hours a host of previously passing date-time serialization tests have started to fail. In particular code warrior 9-4, various gcc, and vc7 were previously passing. I haven't made any check-ins to date-time, so unless someone else has I expect the problem is elsewhere... summary: http://tinyurl.com/ayl5j detailed example: http://tinyurl.com/e2pa5 Jeff
Jeff Garland wrote:
I didn't look at the check-in logs, but in the last 24-48 hours a host of previously passing date-time serialization tests have started to fail. In particular code warrior 9-4, various gcc, and vc7 were previously passing. I haven't made any check-ins to date-time, so unless someone else has I expect the problem is elsewhere...
Well I did some checkins for a CW serialization work around. And I just fixed part of that for GCC. Last night, it's mid-day for me, I also fixed those datetime serialization tests because Robert put it a check for ordering the includes. So the errors might go away soon. We'll have to see. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Sat, 04 Jun 2005 11:55:09 -0500, Rene Rivera wrote
Jeff Garland wrote:
I didn't look at the check-in logs, but in the last 24-48 hours a host of previously passing date-time serialization tests have started to fail. In particular code warrior 9-4, various gcc, and vc7 were previously passing. I haven't made any check-ins to date-time, so unless someone else has I expect the problem is elsewhere...
Well I did some checkins for a CW serialization work around. And I just fixed part of that for GCC. Last night, it's mid-day for me, I also fixed those datetime serialization tests because Robert put it a check for ordering the includes. So the errors might go away soon. We'll have to see.
Ok thanks... Jeff
In the course of making the auto-linking optional. It became necessary to require that all archive/*.hpp headers be included before all serialization/*.hpp headers. Before this was only enforced for those programs which included serialization/export.hpp. This new requirement broke some of my own tests with very confusing errors. So I added code to explicitly verify that this requirement is met and emit a useful compile time error message. Downsiide will break some user code and tests Upside the break will be trivial to detect and fix inclusion of serialization/*.hpp will not trigger requirement for the pre-compiled library. In the past, this prevented BOOST_CLASS_EXPORT(T) from being in the header for class T, where it logically belonged. Several people complained about this. With auto-linking, the libraries were required every time a serialization/*.hpp file was included - even though nothing was invoked. All this should be fixed now. Also, Rene has discovered the way to get the Metrowerks tests to pass. Overlapped on my changes above are his to address this problem. So for a day or two there may be some confusion but hopefully the final result will be much better test results and a much more useful serialization package. Thank to everyone for their patience Robert Ramey Jeff Garland wrote:
I didn't look at the check-in logs, but in the last 24-48 hours a host of previously passing date-time serialization tests have started to fail. In particular code warrior 9-4, various gcc, and vc7 were previously passing. I haven't made any check-ins to date-time, so unless someone else has I expect the problem is elsewhere...
summary:
detailed example:
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
In the course of making the auto-linking optional. It became necessary to require that all archive/*.hpp headers be included before all serialization/*.hpp headers. Before this was only enforced for those programs which included serialization/export.hpp. This new requirement broke some of my own tests with very confusing errors. So I added code to explicitly verify that this requirement is met and emit a useful compile time error message.
Downsiide will break some user code and tests
Upside the break will be trivial to detect and fix inclusion of serialization/*.hpp will not trigger requirement for the pre-compiled library.
I hope that you do not mean that there will be an end-user requirement that serialization header files be inserted in a particular order ? If so that would be really bad IMO. Clearly one can control internally, by checking header file guards, the order in which header files are included if that is necessary, and I do not believe it can ever be right to force an end-user to include header files in a particular order in order to compile modules.
participants (2)
-
Edward Diener -
Jeff Garland -
Rene Rivera -
Robert Ramey