Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-12-02 21:34:39
On 02.12.2017 15:58, Domen Vrankar wrote:
> Stefan I have one suggestion - maybe a stupid one but that's for you
> to decide...
> Since Faber is meant to be a cross platform build system and CMake is
> a build system generator you could perhaps start by competing with
> other build systems by attempting to integrate Faber into CMake as yet
> another build system along side Makefiles, Ninja...
What would be the point of that ? Do CMake users really care what build
system "backend" is being used ? I thought the goal was for them to only
interact with CMake itself ?
I expect Faber to get most publicity from its simple and portable
interface, which wouldn't even be visible if it were used as a CMake
backend. Moreover, CMake as a build script generator produces extremely
ugly and unreadable Makefiles. That's in the nature of the approach of a
macro-language. The Makefile has degenerated into an intermediate
representation, not something for a human eye to dwell on. Doing that
with Faber would be entirely pointless, I think. Though I may
misunderstand either what you are suggesting, or even the way(s) in
which users use CMake.
> C++ evolved on top of C, CMake evolved on top of existing build
> systems so I don't find it a bad idea to hitch a ride on CMake with
> Faber and improve them both by doing that.
Not everyone agrees that it was to C++'s advantage that it was
(initially) promoted as "C with objects". But let's not digress.
I'm (obviously) not against the idea of layering new frontends over
Faber. In fact, I have designed it to be usable as a library, precisely
so people can extend Faber with frontends (for example graphical ones).
But I think I'd spend my time more wisely focusing on Faber itself, its
missing features, documentation, etc., and let those who like working
with CMake add and improve bindings to build system backends.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk