I've avoided pulling in the Boost libraries for a long time. That's partly because I don't want to get into depending on five hundred things, all of which have to be in perfect working order, and partly because when I started aptitude they were still a little new and I wasn't sure that I wanted to depend on something that might be a moving target.
Anyway, my concerns on the second point are long gone -- Boost is popular and widely used. As for the first one, I think that the time I'll save by not implementing stuff that's in Boost will vastly outweigh any time spent dealing with dependency issues. I am in the process of preparing a commit that will cause aptitude to require Boost to build. If you're tracking the Mercurial tree, you'll want to install libboost-dev. The immediate "last straw" was that I wanted an extensible hash table, which Boost has a very nice implementation of. But there's lots of other good stuff in Boost; on at least a monthly basis, I find myself wishing that I could access some part of it for a task I'm working on in aptitude. For instance: the Boost unit test framework is quite a bit nicer (IMO) than cppunit. At some point I may convert the aptitude unit tests over to Boost.Test, or perhaps start writing new tests using Boost.Test, converting the old ones incrementally as needed. That leads me to my second point. If you write code that pulls in a new Boost header, please add it to the list in "configure.ac". I have written a test script that will run on "make check" to verify that the set of Boost headers the configure script looks for is exactly the same as the set of Boost headers that are actually included. But you can avoid breaking "make check" if you just update the list in configure.ac as you go. :-) Daniel _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/aptitude-devel
