On 03/04/2007, at 22:54, Jeff Garland wrote:
Right, and best case, you're into an hour or two of fiddling around that had nothing to do with what you were trying to accomplish -- which is simply to read the docs and use the library. And while I understand the sentiment the C++ programmers have been dealing with this for years, etc, etc.. it's still really nice when getting started with a new lib that the barrier to entry is more like a scripting language than traditional C/C++ libs.
Exactly. I have recently been experimenting with other languages, and their ability to painlessly install and use external modules is great. In C/C++, it's certainly more difficult, and in the case of Boost, it is painful for binary libraries. And I know what I'm talking about fairly well: I'm the maintainer of the Boost packages in pkgsrc (a package system that runs under e.g. NetBSD and OS X) and I had a very hard time to get the packages to work and to get those programs that need the binary libs to compile fine. The "suffixes" and versioning of Boost make things more complex when compared to those libraries built by the typical automake/autoconf/libtool system. (I have almost no experience with Win32, so I don't know what problems arise there though.) When I was suggested to code Boost.Process as headers-only, I was reluctant at first but came to like it in the end. The easiness in using the resulting library is very convenient, and you avoid all the problems of binary libraries. I wish I could avoid having to convert the library to binary just because Boost.System... but I've been told recently that Boost.Asio has the same problem... -- Julio M. Merino Vidal <jmmv84@gmail.com>