Irrespective of what happens with the CMake vs BBv2 debate, it's apparent that there is still plenty of support for bbv2: indeed, I would echo comments that it's a pleasure to use, provided you don't need to dig in and write new rules yourself :-) So, can we improve things to the point where 99% of the remaining issues are dealt with? I think so, the things that come to mind are: 1) Consistent command line options (as Vladimir has already brought up): use "feature=xyz" or "--feature=xyz" consistently throughout. The first of these looks to be the more commonly used within BBv2 at present, so I'd vote for that, and keep "-" and "--" options for controlling how bjam itself behaves (as in the -d and -a options). 2) Better docs. Yes, I know it's been said before, but we really must get the existing toolsets and their options documented. This need not take too long if someone would step up and volunteer to do it. 3) Most of the current problems seem to stem from folks trying to build with non-default options. Can we have a consistent way (across toolsets) to inject compiler or linker specific flags into the command line: actually I suspect we may have this already? If so it needs documenting and pointing to from the getting started docs. Likewise a consistent way of name custom-name-mangling the resulting libraries. 4) Relating to the above, I wonder if we could have a "generic" toolset that used the environment variables CXX, CXXFLAGS, LDFLAGS in much the same way that the autotools do. If necessary the top-level configure script could make use of this to behave in a more autotools-like manner. 5) More BBv2 developers :-) I actually think we do tools rather well - both quickbook and BBv2 are so very nearly where they need to be, but just need that final push that only more developers (and a wider audience) can bring. Part of the problem here is that Boost attracts folks interested in C++ libraries, and who don't necessarily want to spend their time hacking Jamfiles or whatever. I'm not sure how solve this, unless maybe these tools can acquire a life of their own outside of Boost as well as within it. Anyway these are just a few random thoughts, hopefully presented in the spirit of trying to find a positive way forward. I'll look forward to seeing what people think, Regards, John Maddock.
John Maddock wrote:
Irrespective of what happens with the CMake vs BBv2 debate, it's apparent that there is still plenty of support for bbv2: indeed, I would echo comments that it's a pleasure to use, provided you don't need to dig in and write new rules yourself :-)
So, can we improve things to the point where 99% of the remaining issues are dealt with? I think so, the things that come to mind are:
<snip> Thank you for posting this list John. I've been scurrying old posts, bug reports, ticket items and listening to IRC to determine what the salient concerns are. Regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 15 May 2007 19:16 To: Boost mailing list; jamboost Subject: [boost] Improving Boost Build?
For what little it's worth, my take on Boost. Build can be summed up: On Boost.Build - when it's good, it is very, very good, and when it's bad it is horrid. On moving to use CMake - Better the devil you know. And anyway my shinking brain is full ;-) Apart from loathing the bizarre syntax of jam, I think the main problem with people using Boost.Build remains the lack of helpful documentation including tons of examples. And, as John has noted with Quickbook, if the minor but really annoying snags can be cured, we have some 1st class tools for builds and writing docs. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
John Maddock wrote:
Irrespective of what happens with the CMake vs BBv2 debate, it's apparent that there is still plenty of support for bbv2: indeed, I would echo comments that it's a pleasure to use, provided you don't need to dig in and write new rules yourself :-)
So, can we improve things to the point where 99% of the remaining issues are dealt with? I think so, the things that come to mind are:
1) Consistent command line options (as Vladimir has already brought up): use "feature=xyz" or "--feature=xyz" consistently throughout. The first of these looks to be the more commonly used within BBv2 at present, so I'd vote for that, and keep "-" and "--" options for controlling how bjam itself behaves (as in the -d and -a options).
2) Better docs. Yes, I know it's been said before, but we really must get the existing toolsets and their options documented. This need not take too long if someone would step up and volunteer to do it.
The doc is much better in the 1.34 release but it is still very difficult to understand in any orderly way. The approach should be: 1) A complete explanation of the syntax elements. 2) A complete explanation of the purpose of each separate type of bjam file. 3) A complete explanation of all of the constructs used for building which can be in the bjam files, and how they relate to each other. 4) Tutorial 5) Examples I suspect all of this is in the documentation somewhere, but it is very difficult to find and learn given the way the documentation is presented. I admit that I learn from understanding the constructs of a technology first, and only then from a tutorial and example, so perhaps my order reflects my way of learning. When a tutorial is presented first, as in the case of the Boost Build docs, and I have no understanding yet of syntax elements or of build constructs and meanings even though I do understand what in general the technology is trying to accomplish, the tutorial is worthless to me. I really do think that for a technology like Boost Build that one needs a pretty good grounding in syntax and constructs before one can effectively use it. I do understand that one can ask questions and get excellent responses, but this does not remove the need for well-organized documentation. The docs are much better, but still difficult to follow because the organization is largely from the point of view of those who largely understand it rather from those who are trying to learn.
on Tue May 15 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Irrespective of what happens with the CMake vs BBv2 debate, it's apparent that there is still plenty of support for bbv2: indeed, I would echo comments that it's a pleasure to use, provided you don't need to dig in and write new rules yourself :-)
So, can we improve things to the point where 99% of the remaining issues are dealt with? I think so, the things that come to mind are:
1) Consistent command line options (as Vladimir has already brought up): use "feature=xyz" or "--feature=xyz" consistently throughout. The first of these looks to be the more commonly used within BBv2 at present, so I'd vote for that, and keep "-" and "--" options for controlling how bjam itself behaves (as in the -d and -a options).
I think people will be confused anyway as posted elsewhere. They don't know which identifiers are features and which are just options.
2) Better docs. Yes, I know it's been said before, but we really must get the existing toolsets and their options documented. This need not take too long if someone would step up and volunteer to do it.
...and who would that be? That's part of the problem. Another problem is that the toolsets are totally inconsistent in how they work.
5) More BBv2 developers :-) I actually think we do tools rather well - both quickbook and BBv2 are so very nearly where they need to be, but just need that final push that only more developers (and a wider audience) can bring. Part of the problem here is that Boost attracts folks interested in C++ libraries, and who don't necessarily want to spend their time hacking Jamfiles or whatever. I'm not sure how solve this, unless maybe these tools can acquire a life of their own outside of Boost as well as within it.
Yeah, that's important. But when even the people originally supposed to be co-developers on BBv2 have been worn out trying to understand the project's code, how are we going to get 3 or 4 more people to devote enough time to actually succeed where others have failed, and then make big contributions? That's the bottom line, IMO. Who is going to step up and devote enough time to make something that can work as well as CMake? In CMake it's one line to build a graphical binary installer. We simply don't have enough time and resources to reach that level of sophistication. Further, the CMake model has some advantages in that it is not trying to do configuration work every time you build. Yes, we could do that in BBv2, too, but personally I just don't see the point in trying to outrun a project that actually has a bunch of knowledgeable developers and company funding behind it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
participants (5)
-
David Abrahams -
Edward Diener -
John Maddock -
Michael Caisse -
Paul A Bristow