On Sun, Dec 02, 2007 at 11:22:42AM +0100, Mark de Wever wrote: > On Thu, Nov 29, 2007 at 08:24:12PM +0000, Jens Seidel wrote: > > On Thu, Nov 29, 2007 at 07:30:11PM +0100, Mark de Wever wrote: > > > On Sun, Nov 25, 2007 at 07:02:38PM +0100, jeremy rosen wrote: > > > > I'll just reply about the boost part... > > > > > > > > yes it was discussed, and the idea of adding BOOST was accepted on > > > > principle > > > > I do not remember any discussion on this list ... > > It was [1]. Also we already use some boost stuff, but it has been copied > to the source tree. At least lexical_cast with some nice enhancements.
Ah, thanks. Strange that I do not remember this. > > As far as I know Boost has no stable API or ABI. Be prepared to depend > > on a single library version which may not be included in any distribution. > > > > I also noticed that many Boost maintainers do not respond and others > > don't want to commit bug fixes for other libraries. Even many very simple > > patches for build errors are ignored. > > Any references for these claims? The first is true for sure. I think I read this first on a Debian list (debian-devel-games?) where the missing stable API was mentioned to be the reason for not using Boost for a project. Since some time I use Boost as well (tests and logging) and I'm subscribed to the devel and user lists. There are I noticed as well that keeping a stable API has no priority. All the time happen discussions to improve Boost (currently there are discussions how to establish a common namespace and header file location usage), binary or API compatibility was never even mentioned. I understand that this has advantages. It is easier to fix bugs or improve the libs this way. It is also done by the Linux kernel this way. But it also could introduce trouble when using it. Probably it doesn't affect core libraries such as smart_ptr but e.g. the Logging library is currently completely rewritten (to be honest, the prevoius version was never offical part of Boost so it may not count). For the inactive Boost maintainer part: Once I noticed that Boost headers create a few compiler warnings and contain sometimes critical errors I started a simple test and wrote a shell script which just iterates about all public header files (excluding private ones in details/) and just compiles #include <boost/this_header_file>. It is a very, very trivial test and I use the strongest compiler settings (-Wall -Wextra -pedantic ...). My initial mail which contained a patch for maybe 10 libraries was nearly ignored. I expected that approximately 5-8 libraries get fixed during a week (as the patches where really trivial: missing include statements, spurious semicolons after function definitions forbidden by C++ and recognized via -pedantic, some unused variable warnings and a few real errors (wrong namespace usage, some g++ 4.0, 4.1 compatibility issues)). See e.g. http://lists.boost.org/Archives/boost/2007/10/128948.php and http://www.nabble.com/Who-has-commit-rights--Use-it!-t4684705.html where I asked why other peoply don't fix these bugs if maintainers are inactive. Remaining bugs from me with trivial patches are: #1332-#1341, #1410, #1432, #1454, #1462, #1463, #1454 see http://svn.boost.org/trac/boost/ticket/1335, ... Please note that I didn't tested the whole Boost archive. I stopped after approximately 15-20 libraries as only 2 or 3 patches where applied until today (but most are open since 6 weeks). I observed this behaviour also for other patches (not from me) as statistics are published about available patches regularly. Currently there are hundreds of tests failing and few of them could be addressed by applying these patches. Now ask yourself: If trivial patches are not applied what happens with real errors? Jens _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
