Re: [Boost-build] Python port development

Subject: Re: [Boost-build] Python port development
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-07-09 10:38:15

> > >  Also, most of the concerns about the language listed above  equally  
>applies
> > > to CMake -- it has crazy language that has no use  whatsoever  outside 
>cmake.
> 
> > I still do not support BBv2 for  Boost.Locale even in the release for review 
>for 
>
> > one simple
> >  reason - there is no even way to do something like find_library, or  
>find_path.
> 
> Just to clarify -- is this the only feature that you thing is  not 
satisfactory
> supported in Boost.Build?
> 

By now way these are only features I miss in Boost.Build.

At least for Boost.Locale these two feature are show stoppers, but for my 
projects I work on, I need:

- Normal readable documentation (that Boost.Build just do not have)
- Build time checks like check if code sample compiles,
- Build time checks like sizeof something.
- Build time checks like check if standard library supports function (build in 
like iconv, socket etc)
- Build time search for specific function is several optional libraries.
- Creation of config.h like files or results of compile time checks..
- Custom build rules like special compiler that compiles one code to other.
- Support of gettext - extracting messages from source code and managing them, 
merging them etc.
- Support of packaging like creation of debs, rpms, msi or just source code 
tarballs.

Yes, Boost has policies that it never uses compile time checks and does this 
with 1001 define, but
it is not suitable for every project
Yes, Boost does not use any localization tools as it is library only.
And so on.

But, you asked what I need from build system? Lots, and Boost.Build provides 
maybe 10% of what
build system is expected to provide.

> > 
> > So yes, you can develop a "perfect" build system  that would not have crappy 

> > language
> > like CMake has, be fast,  efficient and make a coffee for you,
> > but it will take years of hard work  to make it as stable and useful as CMake 
>or 
>
> > autotools are 
> > 
> > today.
> 
> This is FUD, sorry.
> 

Maybe, but I used actively in quite complex tasks Cmake, Autotools, QMake and 
several additional build
systems and I know how badly they behave when something comes to corner cases.

There are actually very few **mature** build systems, and even thous who are 
mature ones have many bugs
and issues.

What I'm trying to say, there are teams who work very hard 100% time on build 
system development
and spend many men-years to make them work, and still they are not always doing 
their job 100%.

So what I'm trying to say: I don't believe you'll be able to create something 
useful and stable
without spending lots of time on it.

It is not FUD. it is reality - build system are far more complex then most 
people even imagine.
And thinking that writing new one that would "do it right this time" is just 
naive.

Best Regard,
  Artyom

P.S.: Just to be clear, I really appreciate the hard work you do. But I just 
want tool that works
      now and not in some future.