Boost logo

Boost :

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2007-04-03 20:30:13

On Wed, 04 Apr 2007 10:18:17 +1000
Matthew Herrmann <matthew.herrmann_at_[hidden]> wrote:

> Hi All,
> Just my 5c on this, but we are using Boost Build to manage our
> software build process. We use a lot of separate libraries and
> compile a lot of code, even for a large compiler farm. Using Boost
> Build, it is trivial to create and use libraries, including 3rd party
> libraries, that

Wow! and I mean it. I tried using Boost.Build as the base for a new
build system, and I could not get anywhere at all. Do you have anything
you could share? the system tiself, any docs, best practices, wiki,
anything at all?

I ended up wrapping the boost bjam stuff with a makefile that setup
stuff and generated what I wanted.

I would LOVE to get in-the-know by someone who's actually used that
system for something other than building the out-of-the box boost.

> I support the idea of header files for convenient use for new users,
> but for libraries that wrap evil C system headers with nice modern
> C++, its against the spirit of the task to still inherit all the
> macro and header ordering hell from the library I'm wrapping. And I
> don't care about optimising by inlining a call to flush to a slow
> disk.

I agree with this as well. In fact, I played with asio to get it to get
rid of the header-only implementation. Soem tricks and you can even
eliminate the IOCTL constants.

> The header-only approach just doesn't scale like object files --
> imagine how slow our builds would be if we had to recompile all the
> I/O code in our operating system every time we wrote a hello world
> application because they'd made it header-only. The solution is not
> to put that code it in a precompiled header and waste memory, but to
> do what the O/S guys have already done: compile it separately and
> just expose the facade through the object file interfaces designed
> specifically for that purpose.

I agree with this as well. Compile times are a huge time sink. We
build on very fast, modern machines with at lesat 2-4GB RAM, and
compiles take a very long time.

> Of course template code is a different kettle of fish.

Yeah... compile times are the biggest reason some of our algorithms are
NOT template/generic.

Boost list run by bdawes at, gregod at, cpdaniel at, john at