[serialization] merge to releasse ready
I want to merge the current trunk version of the serialization library into the release-ready version. I've checked the wiki page and it seems that I've met all the criteria. I'm just double checking. There are some changes that I'm not included right now. Basically these are the original versions of certain modules located in the boost directory. E.G boost/static_warning.hpp. The serialization library doesn't use them any more and each one has been modified to include a #error -... in case someone has used them. I haven't recieved any reports that this has broken anything so I'm presuming that no other library - and perhaps no user application is including them. The question of whether these should be removed is separate from the above. I just thought I'd post this comment before removing them. Robert Ramey
Robert wrote:
There are some changes that I'm not included right now. Basically these are the original versions of certain modules located in the boost directory. E.G boost/static_warning.hpp. The serialization library doesn't use them any more and each one has been modified to include a #error -... in case someone has used them. I haven't recieved any reports that this has broken anything so I'm presuming that no other library - and perhaps no user application is including them. The question of whether these should be removed is separate from the above. I just thought I'd post this comment before removing them.
Robert Ramey
Hi Robert, The reason you haven't had any user complaints is that there hasn't been a release with the new #error-ing version, has there? It's a racing certainty that if you did do such a release then you would get requests to make the old behaviour work when a #define was set (BOOST_PERMIT_DEPRECATED_STATIC_WARNING or something). These files have had a strange status though so perhaps being more cavalier than usual with deprecation is possible. On an implementation note - why do you have an unconditional #error for all compilers and then follow that up with a couple of conditional #{pragma message,warning}s for various compilers... the latter seem redundant (see e.g. http://svn.boost.org/trac/boost/browser/trunk/boost/static_warning.hpp) Pete
Pete Bartlett wrote:
Hi Robert,
The reason you haven't had any user complaints is that there hasn't been a release with the new #error-ing version, has there? It's a racing certainty that if you did do such a release then you would get requests to make the old behaviour work when a #define was set (BOOST_PERMIT_DEPRECATED_STATIC_WARNING or something). These files have had a strange status though so perhaps being more cavalier than usual with deprecation is possible.
My first inclination was to make a "warning pragma". but it turns out to be compiler dependent and I didn't want to mess with it unless it was really necessary. Right now, I only want to merge in the serialization library and leave this as a separate question to be left up to concensus. I have no special interest in the manner which it is handled.
On an implementation note - why do you have an unconditional #error for all compilers and then follow that up with a couple of conditional #{pragma message,warning}s for various compilers... the latter seem redundant (see e.g. http://svn.boost.org/trac/boost/browser/trunk/boost/static_warning.hpp)
It is redundent. I put the #error in there to be sure that when I ran my tests I would detect any cases where I failed to change the library/tests to use the new locations of these items. I wasn't sure whether I should leave in the #error, leave in the #warning, or just remove the files. Robert Ramey
Hallo, Robert. Would it be a problem for you to wait a day or two? I'm about to post a patch to add support for the latest CodeGear (formerly Borland compiler), but I need to check that it's up to date with the current trunk. Cheers, Nicola Musatti Robert Ramey wrote:
I want to merge the current trunk version of the serialization library into the release-ready version.
I've checked the wiki page and it seems that I've met all the criteria. I'm just double checking.
There are some changes that I'm not included right now. Basically these are the original versions of certain modules located in the boost directory. E.G boost/static_warning.hpp. The serialization library doesn't use them any more and each one has been modified to include a #error -... in case someone has used them. I haven't recieved any reports that this has broken anything so I'm presuming that no other library - and perhaps no user application is including them. The question of whether these should be removed is separate from the above. I just thought I'd post this comment before removing them.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/
I'm in no hurry at all. Its a good time for me as I 've done everything that I think I can do to address the last failures in less used platforms. Two platforms that "almost work" are borland and Comeau. Although I've got Borland 5.64 and Commeau installed, I haven't been able to get them to work. Robert Ramey Nicola Musatti wrote:
Hallo, Robert. Would it be a problem for you to wait a day or two? I'm about to post a patch to add support for the latest CodeGear (formerly Borland compiler), but I need to check that it's up to date with the current trunk.
participants (3)
-
Nicola Musatti -
Pete Bartlett -
Robert Ramey