On Mon, Oct 13, 2008 at 1:14 PM, Joel Falcou <joel.falcou@u-psud.fr> wrote:
Several boost libraries compile without any problem on the cell BE processor in PPU and SPU mode like most of the preprocessor or meta-programming one.
However, it's impossible to use any C++ code that include *any* part of std cause it makes the resulting binary too big for the spu linker. For some boost libraries, the std include is merely used for some optionnal display. For others, large parts of functionnalities is made useless.
As I've been toying with this architecture for quite a bit now, I'm on the verge to patch my local boost with a way to detect compilation on Cell SPU and to remove inadequate include from some libraries.
Considering the potential interest in supporting this architecture, would libraries developpers mind if I submit ticket with patches for this support integration when the actual pacthes is aimed at making the core of the libraries to be used on Cell BE SPU and to add things like #error or #warning that explicitely states that this library or features is disabled ? What's the current stance on adding new architectural support into boost ?
It is up to individual library developers to accept patches or not. But I think you will find most developers are receptive if the patches are complete and reasonable and don't have a lot of negative impact on the code.
For some boost libraries, the std include is merely used for some optionnal display.
I've toyed with the idea of proposing a standard BOOST macro form to deal with that. Using the filesystem library as an example, BOOST_FILESYSTEM_LOG would be used like this: #ifdef BOOST_FILESYSTEM_LOG # include <iostream> // needed only if logging enabled #endif --Beman