Peter Poulsen wrote:

I know this sounds insane, but our developers are very happy with boost (who can blame them :-)), and want to have boost available on our embedded systems. We only have 64 mb of flash memory available for the entire system (OS, hardware monitoring and applications) and I simply cannot get boost down to a reasonable size. Am I trying to do an impossible task, or can somebody give me some good advice on how to build boost so it has a more reasonable size?

It's a little difficult to respond to this since a big percentage of Boost is 'header only' and there's no runtime size cost until someone uses a library. And then that cost tends to be 'built-in' to the application that is using a particular library. So measuring the runtime footprint created by Boost is a somewhat difficult. That said, there's good indications from posts on the lists that other embedded developers have successfully used parts of Boost in projects.

Of course what should be done is removing some of the features, and I can probably negotiate with developers about what features we can provide and which have to go. Which one should I try to get rid of first?

I'd make a list of libraries they are actually using -- with special attention to the 'built' libraries: filesystem, signals, date-time (although this one can be mostly inline), program-options, serialization, etc. These are the only ones that have a 'fixed cost of use' which might be cut-down by removing 'unused features' from the library. Anyway, this list would give you a good idea of which parts you really need. Jeff

At 10:37 AM +0100 2/19/07, Peter Poulsen wrote:

I know this sounds insane, but our developers are very happy with boost (who can blame them :-)), and want to have boost available on our embedded systems. We only have 64 mb of flash memory available for the entire system (OS, hardware monitoring and applications) and I simply cannot get boost down to a reasonable size. Am I trying to do an impossible task, or can somebody give me some good advice on how to build boost so it has a more reasonable size?

Of course what should be done is removing some of the features, and I can probably negotiate with developers about what features we can provide and which have to go. Which one should I try to get rid of first?

The most important thing to do is choose a single variant, which was already suggested by Hugh James. Building in release mode with a few libraries --without-xxx in the bjam invocation can easily get you down to something pretty reasonable for that size of system. As an example, "-sBUILD=release <threading>multi <runtime-link>dynamic" --layout=system --without-regex --without-spirit --without-wave is about 1.9M on x86 with gcc4.1. (I offer this example because I happen to have the resulting libraries handy right at the moment, not because this is a particularly ideal choice for such a system. We exclude several other libraries and delete some other .so's by hand for our embedded targets; I just checked a recent build and this part totals up to about 1M for powerpc.) So I would say this is entirely plausible and not at all insane; or if it is, we share in the insanity.