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

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Roger Leigh (rleigh_at_[hidden])
Date: 2017-12-01 23:14:58

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.

Regards,
Roger