Couldn't find this reported in boost archives, but I'm getting the following compilation error: -------- /usr/include/netinet/ip.h:49: error: syntax error before `:' token --------- My configuration: boost serialization 1.31 g++-3.3 linux 2.4 In some cases, I can make this go away by reordering my boost/serialization headers. From what I can tell, there is a struct defined in serialization with the name 'version': namespace boost { namespace serialization { struct version ... } } Which is colliding with the following definition in ip.h: struct iphdr { #if __BYTE_ORDER == __LITTLE_ENDIAN unsigned int ihl:4; unsigned int version:4; // <-== ERROR REPORTED ON THIS LINE #elif __BYTE_ORDER == __BIG_ENDIAN unsigned int version:4; unsigned int ihl:4; #else # error "Please fix <bits/endian.h>" #endif } Possibly triggered by the using statement: using namespace boost::serialization; on line 53 of iserializer.hh , but that's a guess. Heard of anything like this? Russ Balest Robert Ramey wrote:
Johannes Brunen wrote:
And if there are a large number of new things left out by that approach then we should plan another release sooner rather than waiting 4 months.
However, then you need new volunteers which have to spend the time for the whole procedure again.
The release procedure is too onerous. This isn't the problem, it's a symptom of a more subtle problem. If the source of this difficulty can be found can corrected, then releases can occur more frequently. My personal view is that it's a symptom of a development process that couples otherwise independent/orthogonal efforts. This is due to the fact that we're all working against a development tree that has experimental code in it. So minor issues ripple across all efforts.
I could think of a review process which accepts a library only after the list of requested changes has been made.
I would prefere a review process which leads to final acceptance only after a library is 'CVS' compatible i.e. does not yield to any (known) regressions of the existing pool libraries and is equipted with a working testing facility.
The review process qualifies submissions for inclusion into boost. I don't think there are any libraries that have been accepted then suffered changes which made them unacceptable. It's not fair to ask a submitter to require that that he totally "finish" the package before submission when it cannot be guaranteed that it will be accepted. The review process isn't the problem, its working quite well.
It's just that there is more effort than first meets the eye between the time a library is deemed acceptable and the time it is ready for inclusion into boost. The serialization library including code, headers, tests, html, jamfiles, *.bat, and shell scripts is has passed 25,0000 lines. This takes time and no changes in the review or release procedure can change that. There is the review package which seems to work pretty well. But I would be reluctant to check it in as it doesn't match the review acceptance conditions and I'm concerned about trying to maintain a package which I have now moved beyond.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost