[gryan]

It's unfortunate that Boost is an all-or-nothing set of libraries, and the meta-programming in there can be brutal to compile, so for that kind of platform you'd really need to weight the pros and cons of what you're using out of Boost vs. compile times.

However, building the library set and examples and tests is a one-time cost for the non-header-only libraries. And you don't need to compile the examples or the tests. Or the various debug-release combinations.

Plus, why wouldn't you cross-compile, anyway? I do lots of embedded sensor work and I wouldn't think of compiling anything directly on the hardware itself.

[smcl]

This was cross-compiled. We had just implemented the full (as opposed to abridged) C++ libraries so obviously we decided to make sure that our customers could use them fully, however given that this was new support there was a distinct lack of test cases. Someone suggested that Boost exercised this functionality pretty well (some customers previously complained that they had been prevented from using boost before due to our only supporting the abridged libraries so this was actually a good idea), someone decided that I should be in charge of this.

What it amounted to was debugging horrible compiler crashes, broken library behaviour and spending a long time deciphering huge template names. This caused me to hate C++ more than you can ever imagine. I swear whoever decided to stitch templates together in the way Boost does has never had to debug a development compiler, this broke almost every part of the toolchain.

Ugh.

[16s]

You can compile only what you need. It's much faster that way, but if you do a complete build (debug, static, etc) it will take hours. It's not that bad though and certainly worth it in the end.