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:
local NTDEFINES = _WIN _USE_32BIT_TIME_T WIN32_LEAN_AND_MEAN _WIN32 WIN32 _WIN _WIN32_WINNT=0x0500
..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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk