On 01.12.2017 18:14, Roger Leigh via Boost wrote:
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.
Yes, no doubt, that's the selling point. But does it truly deliver on this promise ? As I said, it works until it fails. And when it fails, who will have to help users figuring out what the cryptic error messages mean ? The problem is of course all about division of labour. Some people are platform experts, others are application domain experts. So ideally they collaborate in that the latter write abstract and portable build logic for their respective applications (or libraries as the case may be), while the former make sure that this high-level platform-agnostic logic maps correctly to platform-specific tool invocations. And while this separation of work is sound and useful, the way this is spelled out with CMake injects an extra layer in the middle, so the whole system requires expertise in three domains: * the application domain * the target platform (including target build system) * the CMake mapping logic In an ideal world CMake would hide everything else underneath it. But in reality, the encapsulation leaks like a sieve, so users are forced not only to understand the target logic but also the mapping logic.
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.
"Integration" may mean different things. In Unix dependencies are typically dealt with via (binary) installations, i.e. tools like autoconf or pkg-config (which you mention yourself) are useful in detecting those, and providing flags I need to use to build *my* code using such third-party libraries. If you really want to build my library from source, you'll have to use the build logic of my choice, there is no way around that, as I can't maintain a build system I don't understand. But then again, who would want to build my library from source, other than potential contributors who are willing to understand the build system (which hopefully isn't too cryptic, hence my work on "this tool", as you prefer to name it, rather than using b2).
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.
Now you are mixing different categories of things. Building with different compilers (the MSVC command line tools, mingw, cygwin, etc.) should of course work (and does, with b2 and Faber). That's what "portable build system" means. But using different build *systems* (including IDEs such as Visual Studio or Eclipse) is an entirely different thing. If people want build integration with other tools, they need to maintain that logic themselves. I have seen enough error reports which I don't have any clue how to resolve that I came to the conclusion that CMake goes after the problem in a very wrong way. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...