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

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-12-05 11:41:42

On 4 December 2017 at 23:59, Roger Leigh via Boost <boost_at_[hidden]>
wrote:

>
>
> On 02/12/17 21:34, Stefan Seefeld via Boost wrote:
>
>> Hi Domen,
>>
>> 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.
>>
>
> The main point of this would be to lower the barrier to entry for using
> Faber.
>
> If I wasn't using CMake, I would never have had a reason to try out the
> Ninja generator, and I would have stuck with plain old Makefiles.  The cost
> of switching build systems for moderately large projects is huge, and
> switching build systems by rewriting all the build logic is a big task,
> particularly when you can't know up front if it's going to be worth the
> effort or full cost/benefit of migrating.  I've experienced this first hand
> with project conversions to the autotools in the early 2000s and to cmake
> over the last few years.  It turned out Ninja was a pretty good build tool,
> and is much faster than make, so I got to use a nice tool which I'd
> otherwise have ignored, irrespective of its merits, because I couldn't
> justify rewriting everything from scratch.
>
> Being able to generate Faber build configuration with CMake provides
> similar possibilities.  You can get exposure and real world usage with
> existing big projects, without projects having to commit huge resources to
> wholesale conversion.  This gets you extra testing and exposure, and it
> lets other projects experiment with Faber when realistically they would not
> be able to even think about it otherwise due to the cost.
>
> It might be the case that the stuff CMake generates isn't as æsthetically
> pleasing or as efficient as hand-written files; this is certainly the case
> for Ninja and a bit for make as well.  But, when the alternative is not
> using the tool at all, it's a compromise I can live with.
>
> You are correct that often we don't care about the CMake generator in use,
> if all we want is to build stuff.  But sometimes choosing a specific
> backend is useful.  I use Ninja over make when the system has enough memory
> and CPUs to benefit from it, and have it peg several dozen cores to the max
> (it can make small systems suffer horribly).  I use various IDE generators
> when I need to use an IDE.  If Faber has specific advantages which
> differentiate it from all the others, then CMake support would let users
> opt into using those distinguishing features when they need them.
>
> Please do think about it.  It's an effective way to get Faber more
> exposure, by allowing all the thousands of projects using CMake to build
> with it.
>

I concur. I use the Clion IDE on windows, linux and Mac. I gives a
consistent, reliable, useful interface on all systems without the horror of
using open source editors (none of which since emacs ever work). It uses
CMake files as its project files. If faber doesn't support this, or Clion
doesn't support faber, I'll never use Faber.

Improve CMake, please don't unleash yet another c++ build tool on the
world. We only need one - that works.

R

>
>
>
> Regards,
> Roger
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>