On Fri, Nov 30, 2012 at 3:29 PM, NightStrike <firstname.lastname@example.org>
In the cmake world, to do the same thing, Dave has to be a lot more
knowledgeable of the internals of our project. He needs to know what
languages we use, what compilers we need, how to call them, how to set
them up, what the differences are between them, what specific options
they'll need, etc etc. It won't "just work".
No, actually not. Dave only needs to configure one of those cross-compile configuration files *ever* and use that for *every* CMake project.
And that's only in case CMake is not able to autodiscover the triplet.
Now of course, we could
try to provide these system-specific files that cmake should be giving
us for free, but then we'd have to maintain (thus somehow be able to
test) every conceivable system that our users might have or want to
No, you don't. Either you have not used CMake enough or you have not understood how it works. It's either CMake's or the user's mission to take care of "every coneivable system", not the developer's (at least, no more than in autotools).
[Please tell me if this next section has since changed.]
What I have also found is that cmake places a glaring silly dependency
on the user. while autotools requires sh, a posix-compatiable shell,
cmake requires.... cmake. To build, not to just prepare the
makefiles. Here's why this matters -- autotools projects don't
require autotools to *build* the project. They require a generic tool
that is already required to have a posix system up and running. cmake
requires cmake, which is a specific tool that a user would not
ordinarily have or need or want.
I fail to see why that is a problem.
When I want to compile a C project, I need a C compiler, preprocessor and linker.
When I want to compile a Java project, I need a JDK.
When I want to compile an autotools project, I need sh, which as you have already said, is only half-legged available on Windows. And that's the whole point of CMake, especially when Visual C++ is in the middle. Sure, you can generate makefiles which call cl.exe, link.exe, etc, but in the end, debuggin, profiling, distributed compilation will be a pain, whereas they will work perfectly fine in projects using CMake.
Requiring CMake, a self-contained tool with no dependendies, to compile a project using a CMake buildsystem is no big deal. It might have been 5 years ago, it is not now. Even less on Windows.
Oh, and there is one more nicety about CMake: there is a GUI for users to configure optional dependencies, this-or-that option, etc.
But I'm tired of this discussion. I'll keep using CMake until I find something better. So far, I have not. Neither for open source, nor for work.