On 5/31/13 9:16 AM, Herbert Dürr wrote: > [regarding dropping stlport4] > > The changes to make the codebase ready for native STL support are done. > Builds with stlport4 enabled will continue to work as before. > > I suggest to use the --without-stlport option for all new builds though: > Stlport is a great project, but the versions that OOo depended on had > been released more than ten years ago. The library improved greatly > since then from a feature, performance and standard compliance > perspective. And of course many many bugs have been fixed [1]. In their > stlport5 version they continue to improve significantly. > > Platform STLs have been inspired by stlport, improved greatly too and in > the C++11 standardization process divergent views have consolidated. We > can rely on the platform STLs. I agree that the timing of the suggested > switch is not so good but the switch itself is overdue. A major version > change is the right time to do this. > > [1] relevant examples of fixes that got into stlport releases newer than > the ones OOo depended on can be seen at e.g. > http://stlport.git.sourceforge.net/git/gitweb.cgi?p=stlport/stlport;a=blob;f=etc/ChangeLog;hb=refs/tags/STLport-STLPORT_4_6 > > > On 2013/05/28 2:38 PM, Rob Weir wrote: >> In theory every fix can cause bugs. But some fixes are more localized >> than others. Fixes with localized impact are easier to test. >> Widespread fixes are harder to test, because more code is potentially >> broken. > > The switch was rendered possible by many little changes over the last > couple of months which got our code base more in line with C++11 > expectations. Snapshots based on these changes have been and are already > extensively tested by our great QA community. The switch itself is just > another step in evolving towards a high quality release. > > Additionally testing has it much easier to find issues introduced by the > switch should there be any. E.g. we have many testers and almost a > thousand automatic tests. They work on different platforms. They cover a > lot of different areas. The risk that a regression in that layer could > remain undetected is very low. > > Automated testing ran its 940 autotests (in BVT, FVT, SVT and PVT) on > different operating systems for 32bit and 64bit versions. The > cross-correlation between pre- and post-switch builds is the same as the > auto-correlation for test reruns: the same tests were successful on both > sides, the same tests failed for both sides.
to make clear that this is a very important and useful step forward. We have to do something to be able for a compiler switch and be prepared for the next steps etc.. Not only on MacOS but also on FreeBSD, the clang compiler don't like the old stlport version ;-) To be serious an upgrade to stlport 5 for example won't help us really. It is the same to switch to a new version or to get rid of this external library completely. We prefer the latter one. The working automated tests (at least same result as before) makes me confident that the change is ok. I propose that we prepare the next snapshot without stlport and will see what happened with our testing. If we run into obvious problems with the stl we will switch back immediately. Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
