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-30 13:18:51

Hi Richard,

I'm going to use "b2" rather than "bjam" in my reply, as it really is b2
(or "Boost.Build", if you prefer) that we need to look at here, and
which Faber draws from. bjam is indeed little more than a "dependency
graph manager". B2 layers lots of important concepts over that,
including tools and tool abstractions, features and their mapping to
(tool-specific) parameters, etc.
So I assume you really mean b2 when you criticise "bjam" below...

On 30.11.2017 07:50, Richard Hodges via Boost wrote:
> replies inline
>
> On 30 November 2017 at 13:28, Stefan Seefeld via Boost <
> boost_at_[hidden]> wrote:
>
>> On 30.11.2017 06:57, Richard Hodges via Boost wrote:
>>> This discussion will eventually lead to the realisation that a
>> cross-platform builder tool requires separate concepts for (amongst others):
>>> * source files
>>> * libraries (dynamic and static)
>>> * dependencies
>>> * executables built for the target system
>>> * executables built for the build host (i.e. intermediate build tools)
>>> * scopes
>>> * -D macro definitions
>>> * abstractions of compiler options
>>> * abstractions of build host fundamental operations (environment
>> variables, file existence, file copying, file locks, spawning subprocesses
>> etc)
>>> … and so on.
>> What's your point ? I think everyone understands that.
>>
>>
> My point is that I think it would be useful to focus on this reality in
> priority to a wrapper around bjam.

That's because b2 already *does* support all of the above concepts. And
while they may not be very intuitive to use (hence my focus on a new
"frontend"), I believe that on a conceptual level I can reuse most of
what b2 has to offer, including features, tools, and much more.
So I'd like to ask you to substantiate your claim that these concepts
aren't provided or served adequately by b2 / faber.

>>> To short-circuit the discussion I can offer the following observations:
>>>
>>> * bjam, clever as it is, is basically a form of makefile. It will never
>> be a build tool It’s therefore not useful to anyone but boost maintainers
>> or single-target projects.
>>
>> That sounds like a rather unsubstantial rant. Can you elaborate on what
>> you mean by that ?
>>
> bjam does what makefiles do. It computes and executes configurable
> dependency tree.

It does much more. It defines features and tools, then automatically
detects the build platform and available tools, lets users fine-tune
those, and only then maps a platform-agnostic build description (in form
of a set of Jamfiles or fabscripts) and maps that to a concrete
dependency graph with concrete actions.

>  It remains up to the developer know the specific flags,
> tools, settings etc he needs to build for a given target on a given host.

You only need to know the specific tools and their argument spelling if
the automatic mapping performed by faber doesn't suite you, and you want
to fine-tune the specific commands. But the general premise of faber (as
well as b2) is that it separates the task of defining tools and the task
of defining build logic, as the two are done by quite different sets of
people.

>
>> But, to get back to the original topic (which was the Faber
>> announcement): have you looked at it (either the docs or the code) ? Can
>> you substantiate your claim that it doesn't meet the points in your
>> shopping list above ?
>>
>> I have looked at the docs an the code. You cannot describe a c++ project
> in abstract terms with faber, just as you cannot with bjam or make. You
> still need to know the exact command line options to set for your
> particular compiler and target system.

Huh ?
Counter examples:
https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript
https://github.com/stefanseefeld/faber/blob/develop/examples/modular/fabscript
https://github.com/stefanseefeld/faber/blob/develop/examples/test/fabscript
https://github.com/stefanseefeld/faber/blob/develop/examples/config/fabscript

Where do you see any mention of "exact command line options" in these ?
The first two would even cross-compile out of the box (when compiled
with `faber target.arch=something`), and the latter two only can't
because they need to execute compiled code, and cross-configuration and
cross-testing isn't quite supported yet.

Stefan

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