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

From: David Abrahams (dave_at_[hidden])
Date: 2006-04-24 08:17:48

Rune <rune.sune_at_[hidden]> writes:

> David Abrahams <dave <at> boo...com> writes:
>> Jeff Garland <jeff <at> cry...com> writes:
>> > For example, the big advantage 
>> > of generated makefiles for 'single platform users' is that they use 
>> > whatever the native build system is -- Makefiles on *nix -- 
>> > solution/project files on windows.  
>> >
>> > The nice effect being that no training is necessary to explain how
>> > things work. 
>> 
>> Explain to whom?
>
> For most Windows developers!
> Every time a Windows developer wants to use Boost for the first time he hits 
> the wall with his head when he realize that he must use something else than 
> solution/project files. And in this case it is not even make (or nmake) that 
> needs to be run, but something called bjam, which he probably have never heard 
> of.

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.

>> > The downside is that for Boost library developers on multiple
>> > platforms it's harder because instead of having to understand one
>> > system, you have to deal with different build systems. And it also
>> > complicates packaging because you either deliver all the makefiles
>> > for every platform, make the user generate them, or have platform
>> > specific distributions.  
>
> Yes, this must be a huge downside for the Boost library developers!
> I guess that this is the key point for sticking with BB?

Not exactly.

> 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.  Now (with BBv2) we
have: one toolset file per compiler family, one per replacement
standard library, and one build description per library.

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

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

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

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