on Wed May 09 2007, "Felipe Magno de Almeida" <felipe.m.almeida-AT-gmail.com> wrote:
On 5/9/07, Michael Caisse <boost@objectmodelingdesigns.com> wrote:
[snip]
I see that I'm in a small minority (perhaps a container with size of 1) but this is one of the reasons that Boost.Build has made life easier for me. I have converted all of our internal builds to Boost.Build and am working with several clients doing the same.
Not at all, I'm with you.
When you are building systems that are destined for multiple targets (compiler, OS, threading model and other variants) ... having the build system just handle and understand what to do without my intervention is a selling point. The fact that building a multi-threaded target understands it needs the multi-threaded library versions, where to get them, and how to build them if they aren't there has removed many makefile and build issues we ad in the past.
Same for me.
It seems boost.build is becoming a real burden on boost. I would really like to see boost developing great tools as it develops great libraries.
I think Boost.Build has some great ideas (usage-requirements, anyone?), and should continue as a project in some form. However, build tools are definitely outside our core mission and Boost.Build is taking the resources of several people that could otherwise be making a much greater contribution to Boost, mostly because their regular Boost work depends on it (or because our users will need to understand how to do it and we worry about trying to document it). That's just not practical for Boost, IMO. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com