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.
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 remains up to the developer know the specific flags, tools, settings etc he needs to build for a given target on a given host. This is also true of a makefile. bjam and make are functionally equivalent in that they offer no abstraction in statement of intent.
* makefiles are great for creating dependency graphs. They are suitable
for the output or intermediate stages of a build tool. You build a makefile hierarchy from the build tool abstractions given a target toolset and options.
We already have Scons and CMake, which are both awful in their own way.
I really think that effort would be better spent retro fitting python
(or javascript, or [insert well maintained scripting language here]) into cmake so that cmake becomes beautiful.
Either that, or recreate cmake in python (or javascript), but cleanly,
using the combined knowledge of several years of evolution.
Why the cmake team chose to build their own godawful scripting language
is a mystery to me. I suspect someone just wanted to write a DSL one day and it all got way out of hand (original poster, please take note!)
R
Sorry, but I still don't understand what you are trying to say. (I don't agree that CMake would be great if it used a better language. I think it is flawed on multiple levels. The fact that it wants to be a build system generator rather than a build system probably being the central issue.)
The abstract build system generator feature of cmake is what makes it uniquely useful to me (and half* the world)
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. System discovery of build host and target is very important. This is why gnu autotools was created. The complexity of gnu autotools I suspect was the driver for the creation of scons and cmake. They are better, but not good enough. We don't need** another make. make et-al are good enough for managing dependencies. We do need** a better, more intuitive means of describing a project and its dependencies in a platform-agnostic manner. Stefan
--
...ich hab' noch einen Koffer in Berlin...
* "half the world" - is a rough finger-in-the-air estimate of the
population of c++ developers who need more than a simple makefile (i.e. most of them). ** my opinion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost