Boost logo

Boost :

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


2017-12-02 9:58 GMT+01:00 Domen Vrankar <domen.vrankar_at_[hidden]>:

>
> 2017-12-02 1:00 GMT+01:00 Stefan Seefeld via Boost <boost_at_[hidden]>
> :
>
>> On 01.12.2017 18:14, Roger Leigh via Boost wrote:
>> > On 01/12/2017 22:09, Stefan Seefeld via Boost wrote:
>> >
>> >> On a more philosophical level, I think that CMake is an attempt to
>> patch
>> >> over the fact that the underlaying build systems aren't portable. So
>> the
>> >> real fix to that problem obviously is to write such a portable build
>> >> system that would obsolete the need for something like CMake.
>> >
>> > No, I think this is missing the major selling point of why people use
>> > CMake. It's glue which can integrate with all the major extant build
>> > systems on all the major platforms.
>>
>> Yes, no doubt, that's the selling point. But does it truly deliver on
>> this promise ? As I said, it works until it fails. And when it fails,
>> who will have to help users figuring out what the cryptic error messages
>> mean ? The problem is of course all about division of labour. Some
>> people are platform experts, others are application domain experts. So
>> ideally they collaborate in that the latter write abstract and portable
>> build logic for their respective applications (or libraries as the case
>> may be), while the former make sure that this high-level
>> platform-agnostic logic maps correctly to platform-specific tool
>> invocations.
>>
>
> There is another side of the medallion here. I tend to move away from
> libraries
> which use custom build tools (python based or b2) if at all possible -
> even when
> it comes to autotools and CMake projects I'll always prefer the CMake ones
> as they both may fail and for CMake + Makefiles I can fix the problem
> myself
> while with autotools I can't (and I really hate to ask what's wrong and
> hate a
> bit less googling what the solution is). CMake allows me to use the tools
> that
> I'm familiar with (e.g. Make instead of Ninja).
>

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... This way people like me could
get used to your build system (if it proves that it has real advantages
over the already existing alternatives), can see which features/workflows
are missing from Faber and which could be improved in CMake that would
perhaps be mapped one to one between Faber and CMake.

This way Faber gets more publicity, real world experience, can better show
it's worth compared to other build systems and people get a bit more
familiarized with Faber before you try to force their switch from
CMake+Faber combo to Faber only. Added bonus is that you only compete with
other build systems instead of trying to convince uninitiated like myself
to prefer a build system to CMake build system generator.

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.

Regards,
Domen


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk