[Boost-build] it's new improved crazy christmas

Subject: [Boost-build] it's new improved crazy christmas
From: Gevorg Voskanyan (v_gevorg_at_[hidden])
Date: 2010-07-09 15:50:33

Artyom wrote:
> 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 
the system.

> 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 
>time, 
>
> >I 
> >
> > would be happy to find it can be  built  with Boost.Build, but if that 
>wouldn't 
>
> >be 
> >
> >  the case, I won't hesitate a  second at implementing Boost.Build support  
>for 
>
> > 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 :)

> Artyom

Gevorg