Boost logo

Boost-Build :

From: mmarcus7 (blazer_at_[hidden])
Date: 2005-06-15 13:32:11

> This change has cost us a fair amount of time so far. First we had
> figure out why, after upgrading and cleaning, our IDE-based client
> projects were breaking. Second we had to try to determine whether
> was intentional BBv2 behavior or a bug. Since we couldn't find any
> documentation about the change we posted here and waited. Third we
> (still) have to figure out a new Jamfile structure to support our
> desired workflow. It would be great to have some guidance on this
> point.

Maybe I should provide a few more details about our "desired
workflow". Our top-level Jamfile is here:


We have been using aliases to force desired targets to build,
including some boost libraries on which our own library depends
(thread, signal and filesystem). After issuing a call to, say, bjam
gcc at the top level, for example, we find the boost filesystem lib


Now we can provide our library clients with an IDE-based project that
statically links against the boost filesystem lib by adding:


to the list of library search paths (e.g. with -L). We also must tell
the IDE that we will be linking against boost_filesystem (e.g. with
-l). This all works fine with BBv2 from 1.32.0.

In CVS BBv2 the built filesystem library is now named


Unfortunately, some platforms, such as the gcc-based XCode IDE for
darwin, will not recognize artifacts as libraries unless they have a
specific extension, so our IDE-based projects that try to link against
the boost libs no longer work.

I don't claim that our Jamfiles our the best possible--any suggestions
for improvement are welcome. But the particular issue that I am
interested in solving in this thread is the suffix problem. Perhaps I
should be avoiding aliases?


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at