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

From: David Abrahams (dave_at_[hidden])
Date: 2006-04-24 12:26:24

Rune Sune <rune.sune_at_[hidden]> writes:

> --- 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.

That's not the point.  Now users get straightforward build
instructions rather than being told to add the source files to their
projects and define this-and-that, they have shared libraries
uniformly, we have a reasonably robust and efficient testing system,
so users get more reliable and portable libraries.  The other
lack-of-system leaves developers without the means to do a good job,
which means that users get worse service.

>> > 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. 

Yes, we know.

> 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. 

The user doesn't have to grasp all of BB.  We just need improved
getting started directions, which I am writing.  Only a very small
amount of grasping is required.

If you want make- or dsp- files (note that dsp files are platform
*and* compiler-specific), figure out a way to generate them from
within Boost.Build, and we'll include them.

>> >> > 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.

That's a more appropriate response, IMO, than jumping on a "dump BB
and use MPC" bandwagon.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com