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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk