Re: [Boost-build] Future development

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-10-06 06:38:51

David Abrahams wrote:

> I understand.  Well, I doubt if anything said here would convince
> Volodya to discard the bjam codebase and adopt something like Doug's
> 8000-line replacement, 

This is funny argument -- it sounds like we're replacing 
something big and complex with 8000 lines of code. But let 
me point that Boost.Build download is 1.5M and CMake is some
2.5M. 

Let me also point out the core code implementing high-level
features that distinguish Boost.Build (in the 'build' directory),
is 9129 lines of code. 

So, that "8000" is nice-looking number, and it has no practical
value.

In fact, this entire thread has went astray -- it turned into
general build tool comparison. It's very hard to
make an accurate comparison of build tools, and produce a
definite answer. The arguments like current number of users
are too simplistic. Arguments about ease of maintenance, 
necessary depend on personality of the person making an assessment. 
Arguments about use of use -- well, I doubt everybody participating
in this thread know what problems users have on IRC. And we have *no*
idea whatsoever what support problems CMake has. Ah, and why
don't we consider SCons? But we're not writing a PhD thesis
titled "what's the best build tool". Instead, we're figuring
the best path forward for Boost.Build, and the best path
forward for Boost's build system.

I started this thread by stating that Boost.Build has a certain
problem, and saying I plan to solve it by Python port. Clearly,
porting 9129 lines of code is not very scary (and porting tools
is trivial), so if that solved the problem of arcane language, 
we're got better. And if we also improve docs, it seems like
most problems *I* see will go away. So I prefer this path.

Instead, a proposal is made to use CMake as a base. As I say,
the internal language on Python is not widely known, so this proposal
does not address my original concern. It probably addresses other
problems, but the specific list of them is not provided, so we cannot
be sure it fixes them. It's also big change. I'm obviously sceptical.
And as I suspect that learning all details of CMake will take me as much
time as finishing the Python, I'm not keep to jump into cmake.

So, to promote Cmake either as new Boost's build system, or as
basic of Boost.Build, it's necessary to either:

        - Provide lots of specific compelling arguments
        - Just have CMake solution fully finished, tested, and
        get most users of Boost or Boost.Build to like it better

So, we probably stop making interesting, but unduly abstract arguments that
are not helping anybody.

- Volodya