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