Re: [Boost-users] installing boost at work

________________________________________ From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Sohail Somani Sent: Friday, February 02, 2007 10:40 AM To: boost-users@lists.boost.org; boost-users@lists.boost.org Subject: Re: [Boost-users] installing boost at work -----Original Message----- From: boost-users-bounces@lists.boost.org on behalf of Nat Goodspeed [Nat] we checked the Boost sources & includes into a subtree in our version-control system. we created platform-specific project files and build them along with our own source code. ------------- I do the same thing but I'm curious why you wouldn't just use bjam to build boost? [Nat] That was the first thing we tried, but it failed spectacularly, with voluminous and mysterious output. After a few hours of fruitless twiddling, punctuated by exclamations at the opacity of bjam config files, command line syntax and documentation in general, our frantic combing of the Boost documentation turned up the interesting fact that it also endorses the idea of building Boost libraries with your own toolchain. We grabbed that ball and ran with it, and have never looked back. My colleagues and I have used a lot of computer languages and are not afraid of learning new syntax. But concerning bjam, I'd better stop now lest this message devolve into outright flame. ;-) I like the *idea* of a truly cross-platform build tool. But traffic on this list suggests that, rather than making life easier, bjam is a major stumbling block for a significant number of would-be Boost adopters. To be fair, there's room to hope that the build system v2 is significantly easier to use. None of us here have any desire to investigate, though. And the build-problem messages from other people keep coming in. [Sohail] One thing I do is also check in the binaries per platform/compiler/variant and the build scripts are smart enough to know where to look. The logic behind this was that there is no point rebuilding as 90% of the developers would use the same platform and that the builds would just build our code. [Nat] I've worked with homebrew build systems in which dependency analysis can fetch unmodified executable/library modules even for your own code. It's a good optimization, though it can be a bit finicky to get it right. And you do have to establish the convention that in case of a mysterious crash, do a full rebuild and try again. That said, as I noted earlier, most of the time Boost modules are only built the FIRST time a given developer fetches them from the version-control system. The cost quickly amortizes away.
participants (1)
-
Nat Goodspeed