From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-10-07 04:35:25
Hugo Duncan wrote:
> I am feeling brave, and thought I would add my perspective on boost.build.
> I have been using boost build in various projects for several years and I
> love the concept of boost.build. It can however be very annoying to use
> (but I am still using it).
> Annoyance number one has to be the error messages that it generates. It
> is usually the case, at least for the type of errors I seem to make, that
> the error report consists of a stack trace mentioning all sorts of BB
> functions, but no mention of even which jamfile caused the error, let
> alone which line of that file. This is the case for such simple syntax
> errors as forgetting a semicolon. This is very user (developer)
> unfriendly, and is a major barrier when first writing jamfiles. The
> amount of debug information available with the debug switches is
> impressive, but overwhelming for the uninitiated.
The point is taken.
> Annoyance number two is that it seems very fragile. Eaxmples: the
> reliabilty of cross (sub-)project dependencies seems very sensitive to the
> exact way they are specified, and I have had to delete precompiled header
> files several times because they were not be correctly regenerated.
Can you explain this in more detail?
> Apart from that I have tried several times to extend boost.build, for
> example to run wix, or to build fortran, or to generate lib files from
> dll's. My experience is that it is difficult to extend BB without being
> intimately familiar with its implementation. Every time I have failed to
> imlement all the functionality that I was after, so I have given up on
> doing this, and resort to makefiles for anything that isn't directly
> supported by BB.
Again, it would be nice if every time you run into such roadblock, you report it.
At the very least, the extender's manual surely has to be augmented with new information,
but what information, exactly, is more like a question to users.
> Boost Build does many things right. The implementation is not perfect.
> The "interface" for extending BB is not perfect. I think many involved
> recognise this and would like to address these issues. Maybe some
> discussion on what the BB "extenders interface" should look like would
> help in choosing implementation technologies.
Well, any thoughts you might have on that are appreciated. You can
either post them here, on add to:
> A rewrite at any time is very prone to failure (eg. Tim Bray just pointed
> to http://chadfowler.com/2006/12/27/the-big-rewrite) and I would hate to
> see further development of BB jeopardised by a split among its
> developers. I have become accustomed to the power of BB, and am very
> thankful to all who have contributed to it so far.
I really think that this particular rewrite is going to be less painful than
some other rewrites ;-)
Thanks for your comments. In order to systemize various goals, I've put
together as Wiki page:
Anybody should feel free to add content to there.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk