I don't remember all of the details, but a while back we went through
the experiement of implementing parts of our build in both bjam and
scons. Probably the single biggest benefit that scons had over bjam
(and the other options we looked at) was the use of python. It was very
natural and comforting, whenever we can across a wierd corner in the
build, to just write some python code to deal with it. I seem to
remember scons being better documented, although it was perhaps just
more intuitive.
In the end, both build systems worked just fine, IIRC, and we stuck
with scons for the reasons above. Since then, we've come to place a
great deal of faith in scons. It's a great crutch, in fact, as it's
extremely good at determining when stuff is out of date (this also
makes it pretty slow sometimes). I've found, for instance, that bjam
doesn't seem to notice when I change compile-time definitions (i.e. for
the signals lib namespace), while scons does.
Austin Bingham
Hi,
On the Boost.Build list we were just discussing the fact that some
people otherwise inclined towards Boost have chosen Scons over
Boost.Build. It would be useful for us to understand some of the
reasons why, if some of you wouldn't mind letting us know. No flames,
please!
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users