Re: [boost] build system (was Summer of Code 2006)

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.

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