Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Domen Vrankar (domen.vrankar_at_[hidden])
Date: 2017-12-03 00:47:37
2017-12-03 1:20 GMT+01:00 Stefan Seefeld via Boost <boost_at_[hidden]>:
> On 02.12.2017 19:12, Domen Vrankar via Boost wrote:
> > And as I said as a front end it doesn't really add anything worth
> > mentioning - just puts a different make up on it.
> no need to defend CMake. If you like it, by all means, keep using it.
> I have described at length what I think is wrong with CMake, and I know
> lots of people who agree with me (even if they don't think that Faber is
> the solution to those problems).
> I don't intend to convince CMake lovers to switch away from their tool
> of choice, but I do offer something for those who need a portable build
> system but aren't satisfied with either CMake or b2.
You misunderstand me. I'm not defending CMake. Quite frankly I wouldn't
care if at the point in time CMake was created and started getting popular
Faber would be created instead and CMake would be presented here now - I
would "defend" Faber in that case.
What I am defending/am against is the idea of creating alternatives without
a large benefit (that's how I see Java compared to C++ all this years...
development landscape fragmentation instead of improving existing in a
compatible way). Every alternative that I stumble across makes my life
harder so I really like the alternatives only when they are really
meaningful and not just a matter of taste.
At work I'm using CMake. A few weeks ago I had to decide between Botan and
Cryptopp library and first I saw Botans "C++11 library" advertisement so I
thought I'd give it a try first. Then I saw it has a non CMake build system
and got the "python not found" error message... So I downloaded Cryptopp,
saw the CMakeLists.txt file, ran the build and noticed that target
importing doesn't work - I found out that CMake is community supported but
didn't have a problem fixing it and decided that I'll probably contribute a
fix once I have the time. After that I just deleted Botan as I knew that
both can do what I need.
Creating a new build system without a real advantage that couldn't be
fairly easily added to an already existing (meta) build system is from
where I stand just another obstacle which I'll have to learn to avoid
without getting anything more in return than I'd get if the author would
have used a common solution instead.
>From Boost I always used the libraries as I didn't have good alternatives.
It uses b2 so I even thought about using it instead of CMake for my own
projects (that was 5 years ago if I remember correctly). Then I skimmed
through the documentation and decided against it - I figured out that it'd
be harder to explain to others than CMake and wouldn't make my life easier
as we still used some libraries that were CMake based. So since I just had
to compile it for AIX and had the instructions/patches from IBMs site I
just built it and was OK with that. I would have liked if b2 would create
CMake import files and that would be it.
Since b2 didn't get enough popularity outside Boost and CMake already
provides a find package script for it it didn't change much for me anyway.
When the "Boost moving to CMake" announcement came I just thought to myself
"Interesting. I hope that now they'll finally provide a target import file
for CMake" and that was it.
But creating a new build system that could potentially become more popular
and really fragment my workflow is a completely different thing - and
that's what I'm against... I'm a bit afraid that what b2 didn't manage
cause Faber would.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk