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-01 23:45:01

2017-12-02 0:14 GMT+01:00 Roger Leigh via Boost <boost_at_[hidden]>:

> 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.  As a library and program author, my
> end users all want to have my software integrate with their existing
> systems.  They wouldn't be happy if I dictated they use some spiffy but
> nonstandard and incompatible system.  But that's basically what Boost does
> with b2, and this tool.
>
> Some users want to build with make on Unix.  Others want to build and edit
> within Visual Studio on Windows.  Or use CLion.  Or Xcode, or Eclipse.  Or
> use MinGW or Cygwin on Windows, with the tool of their choice.  Or use
> Ninja on Windows or Unix because they want fast builds. There are lots of
> different requirements and preferences.  CMake satisfies them very well.
> It might not be the prettiest language, or the most cleanly designed
> system, but it works.  For all of these cases, and more.  And as the
> software author, I write the build logic once and don't have to personally
> care about all the systems I don't use or dislike aside from some CI
> testing.  I can't do any of that with b2, and presumably this tool as well.
>
> Making a "portable build system" ignores the fact that none of these
> people *care* about the build system being portable.  They care that it
> works with *their* tools and workflows with a minimum of hassle and the
> maximum benefit to themselves.  People who are tied to a specific IDE
> aren't going to care that the build system is "portable".  They care that
> it works with *their* setup.  Likewise people who want to use make or
> ninja, or whatever.  CMake the tool is portable, so the problem is solved.
> I write the CMake build, they use the tool *they* want.  Not the one I
> dictate.
>
> A grand unified portable build system isn't a bad idea in and of itself.
> But it's not something which any tool will realise in practice in the real
> world.  It's a pipe dream.  We are all tied into various existing tools and
> systems, and we're not going to throw all that out and replace it.  In many
> cases, those decisions aren't ours to make; my end users are mostly in
> different companies and institutions with their own policies and
> requirements (often they don't have a say in them either). Having something
> that works with all the different existing systems is more desirable than
> replacing them.  And that's why I use CMake, so that I can produce software
> releases that each end user can use in they way they need.  It doesn't
> matter that it's a bit ugly and complex, because the value it provides is
> solving the real world practical integration problems which other tools do
> not, and if you want to replace CMake then you need to be solving problems
> at that level as well.  If you get to that point you might find that your
> system becomes a bit ugly and complex too; that's the price for some of
> CMake's backward compatibility guarantees.  All successful and widely used
> systems build up some degree of cruft, and CMake is no exception in that
> regard.
>
>
> Honestly, if a fraction of the amount of effort that went into b2 and this
> new system went into producing pkg-config and cmake configuration files for
> all the boost components, that would be an invaluable improvement to the
> ability of the boost libraries to be used portably and flexibly by other
> projects.  Because for myself and many others, this is a **much more of a
> portability hindrance than any other factor**.  It doesn't matter how
> wonderful the build system is, if the end product of the build can't be
> easily consumed by anyone else.  I've mentioned before on the list just how
> large a burden is imposed on downstream users in the absence of this
> information, and it would be greatly appreciated if the real-world
> integration problems could be given a higher priority.  We already have
> enough build systems to deal with.
>

While I disagree on the CMake being ugly part (for me the ugly ones were
always syntaxes Make files, auto tools templates, b2 files, and build
systems like Maven or any other XML or YAML based build system but that's
probably just my odd personal taste and what I'm used to) I strongly agree
with the rest of it. I've always preferred CMake exactly because I was able
to use Code::Blocks or Visual Studio IDE while others were free to torture
themselves with Eclipse and I was able to simply produce build scripts that
worked on Linux, Unix and Windows without caring which build system was
used underneath for the most of the time (plus the benefits of having a
testing, continuous integration and packaging almost without extra effort).
Also most of the time I find CMakeLists.txt files and CMake scripts
readable and intuitive since the commands are like mnemonics to me unlike
some other hieroglyphic syntaxes - unless somebody goes out of their way to
make them unreadable.

In the end it has nothing to do with the build system. The added value is
exactly the abstraction and the level of control which allows me to either
work with targets and required compiler feature abstractions or I can
easily set per platform/per toolchain compiler flags if I really need to -
it doesn't limit me too much but it also doesn't provide a general purpose
programming language in which everybody could wreak havoc and write an
entire program inside build system scripts.

For me it's simply well balanced in every aspect and readable as it doesn't
try to do everything and it instead knows how to delegate to other systems
what I need to get my job done.

Regards,
Domen