--- David Abrahams <dave@boost-consulting.com> wrote:
Fortunately that will be a non-issue for most windows developers Real Soon Now (like, this afternoon, if I have time to make the posting). Boost Consulting will be hosting a graphical windows installer for MSVC++ 7.1 and 8.0.
Great news!
But what is most important; to make users of the Boost libraries happier by providing Boost in a format that they can use directly without banging their heads, or to make the library developers' life happier? On this list, I think the answer is obvious ;-)
You misunderstand; it's not about developer happiness. If the developers aren't _effective_, how happy can the users be? Before Boost.Build we had, in the worst case, a classic NxMxL problem: N libraries times M compilers times L standard libraries = NxMxL separate build descriptions. That was very bad for leveraging expertise of library authors and platform experts.
Yes, I understand this.
Now (with BBv2) we have: one toolset file per compiler family, one per replacement standard library, and one build description per library.
I'm sure this is very nice for Boost library developers.
But if you want to run the debugger on Windows, there's no substitute for having a native project file.
Sure there is! I run my Boost tests with
bjam ... --debugger="devenv /debugexe"
and it launches the test inside the Visual Studio debugger.
This is nice! But a Windows developer new to BB, who has not bothered to RTFM, would not know this. But even if you are not new to BB, as in Jeff's case, you may not know this...
What's your point?
My point is that the ladder to climb for a Boost newbie end-user is "unnecessary" high. That is, it is unnecessary high from the end-users viewpoint. If the newbie only had the usual interface towards the development project, i.e. make- or dsp-files, he could focus on his key problems instead of having to grasp all of BB. I have climbed this ladder myself and it is not that fun. And I'm still climbing btw - but it is probably just me ;-)
MPC is heavily used for both open source and industrial C++ projects on more platforms/compilers than Boost currently supports. It's what I use for my own personal projects and I've also used it successfully on large industrial C++ projects. MPC could be a very different direction for Boost. Kevin didn't try to sell it as a replacement for bjam, only as an augmentation, but I believe we could adopt MPC and dump Boost.Build.
This would be great for me as a Boost library end-user!
How can you be sure?
You are right, I'm not sure since I have no experience of MPC. And I have seen silver bullets in disguise before... But since MPC has its roots in ACE/TAO I'm pretty sure that it is worth having a look at.
But even after saying all that, I seriously doubt we can consider going away from Boost.Build.
Yes, it is way easier for Boost library developers to stick with BB. I understand this. But again, since there obviously is an interest in "selling" Boost (I'm thinking about the new web page style among other things) a switch from BB to platform specific distributions would IMHO certainly help selling Boost!
That's what the installer is all about.
Again, great news! /Rune __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com