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-29 13:31:01

On 29.11.2017 07:59, Hans Dembinski wrote:
>
>> 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.
>
> This example remains cryptic.
>
> from faber.artefacts...: artefacts? The term "artefact" is very
> general and non-descriptive. The first definition provided by Google
> is essentially "human-made thing".

Right, it's what "faber" generates (using the same stem even).

>
> Then, I have to type many redundant things here. Note, the many
> occurrences of greet in these two lines
>
> greet = module('greet')
> hello = binary('hello', ['hello.cpp', greet.greet])
>
> It seems like hello is a binary which depends on 'hello.cpp' and the
> module greet. Why the latter?

"hello" is a binary built from a "hello.cpp" source file and a "greet"
library provided from another ("greet") module (thus using Pythonic
syntax, we refer to the latter as "greet.greet").
If the library would have been built by the same module, the above would
simply be

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

as is in fact done in this example:
https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript

>
> The rule to make a test is very cryptic. The action takes several
> positional arguments, and I can only guess what each positional
> argument does.

rules take at least two (positional) arguments (an action and a name for
the target artefact). All other arguments have default values, and thus
*may* be given as keyword arguments or as positional arguments,
depending on your preference. (But given that a "source" argument is
still very common, I just chose to not spell it out as "source=hello"
for compactness.) As a fabscript author you are of course free to name
all your rule arguments, if that helps readability. I not inventing
anything here, but rather take the most natural approach possible
following Python language rules and idioms.

> I am also critical about this in bjam. By using a syntax that uses a
> lot of positional arguments, you need to read the documentation to
> figure out what is going on.

Again, Python allows you to name all arguments. This is up to the
caller, not the API designer. As far as the API is concerned, rules have
two mandatory arguments, so it wouldn't make sense to make them keyword
arguments.

But if you prefer some help in drafting your fabscript logic, there are
good tools to help interactively editing Python code, including code
completion etc.
That's the beauty of using Python: we can tap into a fabulous ecosystem
of tools and modules, including ipython, jupyter, spyder, etc., etc.
In any case, nothing is cast in stone just yet. One reason I decided to
publish Faber now was to gather feedback and interest in collaboration,
and I expect lots of things to change as we collectively improve upon
what's already there.

> If you are lucky, the author provided comments for each positional
> argument, but then one might as well use keywords which are
> self-documenting. This is what CMake does well, IMHO.

Stefan

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