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

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2017-12-01 20:42:16

> On 30. Nov 2017, at 14:38, Stefan Seefeld <stefan_at_[hidden]> wrote:
> 
> Ah, well, now that's a fundamental limitation of Python. […]

Ok, if you use a standard Python interpreter, then it wouldn't work... except perhaps with really evil hacks.

> I was actually thinking of ways to merge the two (the name of the variable, and the intrinsic names of the library and binary artefacts) to avoid that perceived redundancy, but got in all kinds of additional complexities trying that. The main point being that I really want to take advantage of this being written in a well established language, and using its idioms.
> SCons is a very good (or bad, actually) example of what happens if you technically use an established language without paying tribute to its idioms and established practices. I don't want to repeat that error.

You are right, of course. I am glad to hear that you thought about it. I don't have any other ideas right now.

>> To make the syntax very consistent (the Zen of Python says: "There should be one - preferably only one - obvious way to do it."), you could define all build items like library and binary in this way:
>> 
>> def binary(*inputs, attribute1=default1, attribute2=default2, …): ...
>> 
>> All positional arguments would always be inputs of any kind, like a source file or a library. If you always use positional arguments consistently like this, then my complaint about ambiguity is gone, because there is a clear rule which is easy to remember.
> 
> Perhaps you should think this through for a while longer (the way I have thought about it for months :-) ). I believe you will come to a very similar conclusion as I have.

Well, I am not an expert on how to design a build system, since I have never done that. This sounds a bit like you don't want to explain and discuss this further. That's fine with me, but it would be a pity. I am sure everything makes sense to you, but as the creator you will invariably get "betriebsblind", it happens to everyone. A review is a chance to get a fresh new perspective.

I know next to nothing about b2 and bjam, but I do understand Makefiles, I played with SCons for a while, and I am pretty fluent in CMake. I am very fluent in Python and I love the Zen of Python, which every programmer should put up in their office IMHO. I am also not above admitting, that I am but a simple guy who just wants to have a consistent build system that makes sense, is fun to use, and easy to extend. CMake mostly fails in the latter regard IMHO.

Perhaps more importantly, CMake becomes more ugly with every version, as they try to cram in more and more features without really re-designing the whole thing (reminds me of C++). If this trend continues and eventually enough people get annoyed with CMake, then there would be a market for a new build system. A niche that Faber could potentially fill (although I believe this is hard for any competitor, as explained a few mails back).

Concerning the different perspective; like Richard, I don't understand why you despise that CMake is a build system generator rather than a build system. I don't know why they did that, it seems to make things more complicated for them, but it is not harming me, the user.

>> Attributes would be passed consistently via keywords. They have reasonable defaults that Faber picks for me. Like, if I want another file extension for a library than the default for the platform. For libraries, I could specify whether to build a static or shared one. Or if I really don't want to name the library "greet", I could pass the keyword name="great".
>> 
>> This declaration enforces the use of keywords for attributes, positional arguments are not allowed for attributes, which is a good for clarity.
> That's actually a good point: I can change the definition of these functions (`rule`, artefact constructors, etc.) to explicitly forbid positional arguments for anything but the required arguments. I agree that would prevent certain errors. Thanks for the tip !

At least I was able to provide something useful :).

Best regards,
Hans