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

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-11-22 13:43:11

On 22.11.2017 05:12, Hans Dembinski via Boost wrote:
> Hi,
>
> this is an answer to Richards mail, but I am mostly addressing Stephan.

Let me reply to both your mails here...

>
>> 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.

Not at all. SCons is well alive (and I have contributed to it in the
past, even mentored a GSoC student for it).
There are fundamental differences, though, and (as you mention it) I
think its interface is quite unpythonic, unfortunately, despite the
superficial fact that it uses Python for its SConscripts.

>
> 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.
Yes. But despite its popularity, I disagree with CMake's approach on a
very fundamental level (it being a build system generator, rather than a
build system), as it makes things oh so much more complex. Everything
works well until it doesn't, at which point all hell breaks loose.
That's very typical for macro-based languages (think latex, m4). And it
had to reinvent its own language, in a rather ad-hoc manner (i.e.
started with a simple declarative syntax, but then had to expand on that
to cover other use-cases. "Now you have two problems." comes to mind (if
I may paraphrase).

>
> 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 

I'd contest that. Boost.Build does hide most details about tool
internals (how to invoke the compiler, say), until you need to plug in
your own tools.

> 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. 

Yes, intentionally so. (Well, also because that's what bjam uses, and I
didn't see any reason to change that.) A scheduling tool that invokes
external tools to update artefacts needs some kind of DSL, and I think
constructs such as $(>) seem rather intuitive. The fact that `make` (as
the de-facto standard in UNIX land) uses the same language can only help.

> # 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.

Thanks for your feedback. I may rethink how I document Faber. As a
developer, I typically much prefer a bottom-up approach, starting with
the lowest details, then adding layer upon layer of abstraction. So what
you are looking for is likely persent in a higher layer. Have a look at
one of the other examples:

from faber.artefacts.binary import binary

greet = module('greet')

hello = binary('hello', ['hello.cpp', greet.greet])

rule(action('test', '$(>)'), 'test', hello, attrs=notfile|always)

default = hello

(from
https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript),
which uses higher-level artefacts (`binary`, `library`) and doesn't
require the user to define his own actions to build.

>
> 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.

As much as I'd love for people to adopt Faber, I'm not proposing Boost
(as a whole) to move to any tool in particular. I have expressed this
view in the past, and I don't want to distract this thread (about Faber)
with discussions about Boost's strategy moving forward.

The reason I propose Faber here is as a fork (or, in a way, a new
frontend) of Boost.Build, so people who have been struggling with
Boost.Build in the past may want to look at this as a possible alternative.

Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...