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
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?
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk