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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk