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

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Domen Vrankar (domen.vrankar_at_[hidden])
Date: 2017-12-03 10:02:10

2017-12-03 1:47 GMT+01:00 Domen Vrankar <domen.vrankar_at_[hidden]>:

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

Sorry for another "how about" mail...

I've thought about Faber, what it tries to do and why I dislike it a bit
further and:

How about you add commands to Faber that generate import target files for
CMake and perhaps some additional interoperability things that wouldn't
make my life harder (perhaps even contributing something to CMake in order
to achieve that) in case two projects use different (meta) build systems?
That way you keep your experimental tool which could someday really become
better than CMake and a new de facto standard while not make things harder
and more divided than they need to be.

I just don't want Faber to pretend that it lives inside a bubble and that
CMake doesn't exist or is a competitor that you don't want to know about
and interoperate with - just make them interoperable and try if it
survives. And I'll somehow try to convince myself to install another
dependency (python) just for the sake of using it when either Boost or
other non Boost libraries start using it.

Faber is years too late to not inter operate with CMake and expect people
not to care about that.

Regards,
Domen