From: Rune Sune (rune.sune_at_[hidden])
Date: 2006-04-24 10:05:59
--- David Abrahams <dave_at_[hidden]> 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.
> > 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!
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk