Rune <rune.sune@yahoo.com> 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