On Wed, 04 Apr 2007 10:18:17 +1000 Matthew Herrmann <matthew.herrmann@zomojo.com> 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.