Boost logo

Boost-Build :

From: Phillip Seaver (phil_at_[hidden])
Date: 2006-02-02 12:15:12

Daniel Einspanjer wrote:
> I have a presentation to my engineering team tomorrow where-in I hope to
> demonstrate to them some of the advantages of moving away from makefiles to
> BB. The other alternative on the table is ant + cpptasks.
Hopefully, by "tomorrow" you mean Friday.

I don't know about the best way to do it, since I'm not an expert. I'll
give my opinion, though. :-)

You could shorten your Jamfile a good bit by doing things like:


..and replace the long list with "<os>NT:<define>$(NTDEFINES)"

The defines that depend on build parameters can be done with a feature.
To borrow from the "variant" feature:

feature demobuild : : implicit composite propagated symmetric ;
feature.compose <demobuild>internal : <define>_AN_INTERNAL_BUILD ;
feature.compose <demobuild>acme : <define>CUSTOMER=Acme ;

Then, you can do "bjam demobuild=internal" or even "bjam internal" (due
to the "implicit" above) to do the builds with _AN_INTERNAL_BUILD
defined. A potential downside to that is that everything will be built
separately just like debug and release builds. I haven't quite figured
out yet how to apply a feature like this to selected projects and how to
selectively propagate it to projects that are used by it.

As for things like "<variant>debug:<define>DEBUG", I have them in my
Jamroot as well. I have _DEBUG defined for debug builds and NDEBUG
defined for release builds. It seems like a good place to put them to
me. I also have "build-dir ../bbuild" on the project in Jamroot so that
everything gets built outside of the source tree.

I think the "<os>NT:<cflags>/wd####" lines are specific to Visual C++ .
So, I believe you want "<toolset>msvc:<cflags>...."

Good luck! I hope this helps.

Phillip Seaver

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