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

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-11-30 13:37:13

inline...

On 30 November 2017 at 14:18, Stefan Seefeld via Boost <
boost_at_[hidden]> wrote:

> 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...
>
> I do mean bjam

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

I would argue that the intuitive way to express this is a script that
defines conceptual assertions.

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

Have you tried getting bjam to correctly build boost for c++14 on iOS for a
specific version of iOS, as a universal library?

It's a dark art.

Have you tried to build for emscripten? (internal rules do not work).

I can't even find a reasonable instruction manual to describe how bjam
works. Before building a front end for it, perhaps better to document what
is already there.

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

How would you build a protocol buffers .proto file into c++ using the
correct build options for the target, have the headers and sources
installed to the right places and have these generated files correctly
emplaced in the graph? This is fundamental to my use case.

>
> >
> >> 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.
>
> These examples are utterly simplistic. Nowhere are they setting sysroot,
sanitize, warning options, abstract libraries (with embedded include file
paths) etc.

How would you get these to build as a signed executable on iOS, android for
example? without a 3-line CC=clang++ <insert magic options list here>

>
> Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>