One of the requirements for a continuous integration process is that the build for a specific target be quick. Something under 10 minutes is ideal. I find that when not using precompiled headers, boost can significantly impact the compilation time of the project. I've experienced 20 minute compiles when using boost fairly extensively throughout the code base.

So far I only see two obvious solutions to this problem. First, use precompiled headers. I really don't want to do this because it causes issues with include dependencies and makes the code not reusable as a result. The second option is to beef up the machines doing the compiles, however this can have diminishing returns.

I am sure that a lot of people in the community have had this specific issue with Boost's compile times, as well as in many other areas. What would you guys recommend? Is there any other solution beyond the obvious?

I think most of the solutions have been expanded already: * precompiled headers (I know dependencies are a killer). * Use the Pimpl idium to hide Boost dependencies from class interfaces, and therefore remove them from the build (but then you loose inline expansion which may be an issue). The big question though, is what is it *specifically* that's causing the long compile times? Once you know that you can try and isolate the problem code to a single translation unit. One other thing that may help, if you have headers that make extensive use of metaprogramming via mpl for example: if say 90% of the code is instantiating the same template instances, then providing full specializations of those templates *without* the metaprogramming logic can be a big win. HTH, John.

Robert Dailey wrote:

Hey guys,

One of the requirements for a continuous integration process is that the build for a specific target be quick. Something under 10 minutes is ideal. I find that when not using precompiled headers, boost can significantly impact the compilation time of the project. I've experienced 20 minute compiles when using boost fairly extensively throughout the code base.

You have to remember that CI comes from an area of research in project development that also tells us to split our project into numerous small libraries. Check out RCM's article on "Granularity" and "Stability". If you have extraordinarily long build times you may be breaking one or more of the packaging principles.

So far I only see two obvious solutions to this problem. First, use precompiled headers. I really don't want to do this because it causes issues with include dependencies and makes the code not reusable as a result. The second option is to beef up the machines doing the compiles, however this can have diminishing returns.

You forgot a third option, split your project into numerous small libraries so that any changes require the smallest amount of rebuilding that is possible.

To address this problem, I organize my program into separately compiled modules and these modules into a library. Then I link against this application specific library. So code isn't re-instantiated all over again every time. It does take a little time to re-organize code this way and sometime I just have to explicitly instantiate stuff, but the net result is that compile time isn't an issue for me regardless of the size of the application. BTW 10 minutes is way to long for me. I need more instant gratification - under a minute. Robert Ramey "Robert Dailey" wrote in message news:496954360904261340y1cf6d7d6n40ba23b6e6267d9f@mail.gmail.com... Hey guys, One of the requirements for a continuous integration process is that the build for a specific target be quick. Something under 10 minutes is ideal. I find that when not using precompiled headers, boost can significantly impact the compilation time of the project. I've experienced 20 minute compiles when using boost fairly extensively throughout the code base. So far I only see two obvious solutions to this problem. First, use precompiled headers. I really don't want to do this because it causes issues with include dependencies and makes the code not reusable as a result. The second option is to beef up the machines doing the compiles, however this can have diminishing returns. I am sure that a lot of people in the community have had this specific issue with Boost's compile times, as well as in many other areas. What would you guys recommend? Is there any other solution beyond the obvious? Thanks for your time. ------------------------------------------------------------------------------ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users