2017-12-02 1:00 GMT+01:00 Stefan Seefeld via Boost
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.
There is another side of the medallion here. I tend to move away from libraries which use custom build tools (python based or b2) if at all possible - even when it comes to autotools and CMake projects I'll always prefer the CMake ones as they both may fail and for CMake + Makefiles I can fix the problem myself while with autotools I can't (and I really hate to ask what's wrong and hate a bit less googling what the solution is). CMake allows me to use the tools that I'm familiar with (e.g. Make instead of Ninja). It's a difference between being able to fix it myself or whining to the others or simply abandoning the library (with Boost the last option is a bit hard from time to time). There are of course people who don't have the knowledge about build system on their platform of choice but I'd guess that they'd use binaries if at all possible and not go into the compiling the library land.
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.
I may have too little experience but from where I stand you are exaggerating this point quite allot (while I do agree that Boost libraries are quite often pushing the compilers and error reports to the limit so it may be a valid exceptional point).
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).
One reason for why would be that there is not the latest version in my distro and I need it. And no I wouldn't bother to learn a new build system just for the sake of contributing to one project (unless really forced to) and I keep wondering how many others are like me.
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.
Again I disagree here. This puts an overhead on me that my meta build system could solve but can't due to the choices of other authors. My point is that I like the fact that different build systems exist and compete with each other but want a meta build system to support them so when I choose one over the other I don't have to reinvent the entire build structure of my projects. Regards, Domen