Subject: [Boost-build] it's new improved crazy christmas
From: Gevorg Voskanyan (v_gevorg_at_[hidden])
Date: 2010-07-09 15:50:33
> How did you do this? Using negative array size trick?
Pardon my ignorance, but what is that negative array size trick? I did that by
writing a program that prints a sizeof of a type (which is given by a define
during compilation), running that, capturing the output, and composing a
<define>SIZEOF_WCHAR_T=<the-output> property to pass further as a requirement.
Don't other build systems do it the same way?
> In any way implementing such checks correctly is very tricky and it was done
> right in CMake only in 2.8 I think.
Do you see any potential problems with the approach above? What specific
problems did CMake have regarding this?
> How many developers would actually know to do this right? Not so much.
I can't disagree here. I have looked into the implementation of
configure.check-target-builds rule and built a capture-target-output rule having
the former as a reference for the general structure of the solution. That was
remarkably hard, at least for me. Also it has some rough edges which could be
cleaned up with some help of a Boost.Build guru.
And this exactly shows the point of this thread as started by Vladimir. I had to
mess up with the dark corners of the Boost Jam language, fighting with at times
cryptic error messages, browsing different jam modules to try to compensate the
lack of the documentation, etc. The Python Port will give a language for
_extending_ Boost.Build that is free from these kind of issues, but will keep
the current jam language for _using_ Boost.Build. I like Boost.Jam when just
using the build system, but not so much when needing to seriously extend it.
With Python Port, the situation will change, and more users could easily extend
the build system the way they like, and then we might be pleasantly surprised to
see the lacking features you talk about quickly implemented and integrated into
> So what I try to say is not what is possible, but what is available to user
> via simple line or two and quick glance in documentation.
Nod. Having the features available out-of-the-box is certainly important.
> This is the difference between mature build system and a build system
> that becomes extremely painful when the task become less obvious then
> building a simple library or executable.
I'd say it depends on the actual needs a person has. I did some pretty
complicated things with Boost.Build, and it coped with it pretty well. In other
scenarios, like autoconf-like usage, it's not mature yet, but there are surely
areas where it is mature, beyond building simple targets.
> > P.S.
> > Boost.Locale looks useful, and someday I might actually need it. At that
> > would be happy to find it can be built with Boost.Build, but if that
> > the case, I won't hesitate a second at implementing Boost.Build support
> > Boost.Locale to meet my needs.
> > Just FYI
> Thank you,
> I think I'll eventually write them on my own, but I'll remember the offer if I
> get in troubles :-)
Will be happy to help!
> Meanwhile it still waits in review queue.
> And probably when it will be finally reviewed and hopefully get into boost its
> build system will
> be more powerful then it is today.
I hope that too :)
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