inline... On 30 November 2017 at 14:18, Stefan Seefeld via Boost < boost@lists.boost.org> 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@lists.boost.org> 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