Re: [boost] Announcement: Faber, a new build system based on bjam

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: James E. King, III (jking_at_[hidden])
Date: 2017-11-22 12:20:38

On Wed, Nov 22, 2017 at 5:12 AM, Hans Dembinski via Boost <
boost_at_[hidden]> wrote:

> Hi,
>
> this is an answer to Richards mail, but I am mostly addressing Stephan.
>
> > On 22. Nov 2017, at 09:00, Richard Hodges via Boost <
> boost_at_[hidden]> wrote:
> >
> > Stephan wrote:
> >
> >> In case it isn't obvious: I very much welcome collaboration, so if you
> >> want to contribute (be it more tools or even entirely new
> >> functionality), I'd be happy to talk.
> >
> > Nothing would please me more than to be able to dump the horrific syntax
> of
> > cmake. I have often thought that python would be the obvious language
> for a
> > replacement. There was of course a similar tool called SCONS once, which
> is
> > python also. It seems to have fallen by the wayside.
>
>
> I am not a big fan of CMake and I do like Python very much, but the
> success of CMake shows me once again that people have surprising needs they
> are usually not concerned about how powerful the tool is for the technical
> expert. Mostly it is about making simple things simple and saving time for
> the average guy.
>
> Here is my list why I believe CMake is so popular (ordered by perceived
> priority):
> 1) it is a high-level language for describing build trees, it allows me to
> ignore much of the technical low-level stuff, like how to call the compiler
> with the right options
> 2) the commands have nice long names which makes CMake build scripts
> almost self-documenting
> 3) it ships with a maintained collection of scripts to configure and
> include external libraries
> 4) there is a company behind it which continuously adapts cmake to its
> user base and advertises its use
> 5) the documentation is ok
> 6) it is comparably fast (Scons was rejected because it is slow, AFAIK),
> especially when you use the Ninja backend
> 7) it has a ncurses-based configuration interface
> 8) it produces pretty output
>
> Since cmake has already an impressive following, this adds the most
> important item on the top of the list:
> 0) people already know the tool and don't have to learn it
>
> Boost.Build does not offer points 0-4 and 7 and neither does Faber, it
> seems. The Hello World example in the Faber docs reminds me a lot of
> Makefiles, because of the $(<) and $(>) syntax.
> # define some actions
> compile = action('c++.compile', 'c++ -c -o $(<) $(>)')
> link = action('c++.link', 'c++ -o $(<) $(>)')
>
> # bind artefacts to sources using the above recipes
> obj = rule(compile, 'hello.o', 'hello.cpp')
> bin = rule(link, 'hello', obj)
> test = rule(action('run_test', './$(>)'), 'test', bin,
> attrs=notfile|always)
>
> default = bin
> This looks rather mathematical and abstract. I appreciate math, but many
> people don't. The syntax is very terse, which I think is not good. For
> build scripts, I think that Cmake has a point with its long and descriptive
> names. I touch a build script only very rarely. If I touch it very rarely,
> I want it to be very easy to read, because I forgot all the little details
> of how it works after a few months. I learned CMake basically by looking at
> build scripts from other people, not by studying a documentation from
> ground up. This is incredibly useful, nobody likes to study manuals.
>
> We had this discussion about the pros and cons of CMake a while ago, and
> it seems that nobody loves it, but it still seems like a useful compromise
> for many people. I don't see how Faber can compete with this, and I would
> prefer if we move Boost to CMake.
>
> Best regards,
> Hans
>
>
I thought the decision was already made to move to CMake based on an
announcement that was made a couple months ago?  It's true that sometimes
CMake is lacking, for example it has no built-in support on Windows to
select a static versus dynamic runtime (one can set the compile flags at
generation time however), nor does it do a good job at packaging up PDB
files when building install targets for build types that include debug
info.  That said, I have used it for a long time now (over 10 years) and
find it to be the most complete and easiest to understand/use
cross-platform build system.  Regarding package management, the conan C/C++
package manager team has a project for cmake integration.  Hans summarized
the good points nicely above, but missed a couple key points I find useful
- CMake produces parallel-build-capable build scripts, and it can generate
both Eclipse and Visual Studio projects.  Many open-source projects already
use CMake (which is not limited to just building C/C++ by the way), and
given the active and robust ecosystem that exists around it, CMake will be
my tool of choice for some time to come.

- Jim