2017-12-02 0:14 GMT+01:00 Roger Leigh via Boost
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