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

2017-12-03 1:47 GMT+01:00 Domen Vrankar :

2017-12-03 1:20 GMT+01:00 Stefan Seefeld via Boost :

...

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