Re: [Boost-users] installing boost at work

From: Nat Goodspeed (ngoodspeed_at_[hidden])
Date: 2007-02-02 11:46:36

________________________________________
From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Sohail Somani
Sent: Friday, February 02, 2007 10:40 AM
To: boost-users_at_[hidden]; boost-users_at_[hidden]
Subject: Re: [Boost-users] installing boost at work

-----Original Message-----
From: boost-users-bounces_at_[hidden] 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.