Dave Abrahams wrote:
Part of that is because the design tries to do too much. Specifically, the production of multiple build configurations with a single build command offers most users no benefit in exchange for the enormous complication it causes in design, implementation, and especially in writing build instructions (Jamfiles in our case). For the few who do benefit from the feature, the ability to build multiple configurations easily could have been written as another layer that invokes the build system multiple times.
It would be true if all you ever wanted was to build *everything* using the same set of properties. However, if there's need to variate build properties of specific targets, outer wrapper just will not work. Say, program_option runs some tests using static link and some tests using shared link, which naturally builds the library itself twice with different configurations. Trying to do that with naive wrappers would mean you'd build *all* tests both using static linking and shared linking, at extreme expense of testing time. Of course, you can add some conditional to run some tests using static linking, no matter what, and very soon you'll reinvent all of Boost.Build again. In practice, while new users are often confused about declarative nature, maybe due insufficiently clear treatment of that in the docs, I can definitely tell you that it's not a big problem going forward. Conditional requirements, like <toolset>gcc:<cxxflags>whatever is something that seem to cause next to zero queries on Boost.Build mailing list and on IRC. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40