On Mon, Nov 12, 2012 at 3:22 AM, Xiaofan Chen <[email protected]> wrote: > On Mon, Nov 12, 2012 at 3:55 PM, Pau Garcia i Quiles > <[email protected]> wrote: >> As for your concerns about CMake being available or not: it's >> available from all Linux and BSD variants I know because more and more >> projects are moving to CMake because more and more projects are >> concerned about cross-platform, including MSVC. It's not something >> esoteric. > > As far as I know, there are still a lot of project against the ideas > of using CMake to replace the autotools.
The main reason why we do not use cmake is that it makes things much more complicated for the end-user, while adding additional maintenance requirements that we should get for free from the build system. Here's what I mean. In the autotools world, there is a very defined and extremely enforced concept that above all, our goal is to make it *TRIVIAL* for the end user to compile your software. Now let's clarify this. The end user is the guy who knows nothing about development, nor of your project, nor of autotools, nor of anything else. But he needs your project for some reason. We want that guy to be able to do this: cd /tmp; /path/configure && make And he can do that on ANY autotools project without knowing anything about anything. Our goal is to make it as easy as possible for THAT guy.... **NOT** for the developers on our own project. Kai or Ozkan or Jon or anyone else on our team can figure out how to manage whatever system we have in place with whatever dependencies we place on them (like having a specific automake version). And we can expect project developers to have to learn at least enough to do basic things for whatever system we choose. Moreover, if making the end-user guy's life easier requires making my/jon/kai/ozkan/etc's life harder... that's ok, even if we kick and scream the whole way. But if we make "that guy" kick and scream... he'll just get fed up and use some other project. There's a number of cases like that already on our various projects... it's just plain annoying in some cases to use autotools. The first one that comes up constantly is that autotools doesn't support wildcards, so we have to manually keep a ginormous list of files up to date for building the crt. It's REALLY annoying. However....... doing so makes the end-user's life easier/better/faster/more portable. So, we accept it. What *I* have found in the cMake world is that the developers have to do more work because cmake won't (where autotools will), and worse... the end-user (getting tired of typing that... let's call him Dave...) has to do a lot more work. For instance, let's go back to cross compiling. In autotools, you say "configure --host=triplet", where "triplet" is defined by the gnu config project to support every conceivable system out there. A user can get any autotools project and say: configure --host=my-special-system And it'll compile fine, regardless of what's in it.... fortran, c, ada, asm... He doesn't need to know anything about compilers, or cross compiling.. he just needs to know "I want to build for my-special-system". As project maintainers, we don't need to know much about the target platforms our users might want, either. You can cross compile mingw-w64 from **ANY** posix system out there. And since you typically build it alongside gcc, all of the configure options are modeled after comparable gcc options so that compiling our project is a natural extension of compiling the compiler. We get all of that from autotools for free, without having to write any amount of system specific definitions. We just put: AC_CANONICAL_HOST in our configure.ac, and we're done. We don't have to have any custom m4 macros, any list of supported systems that's always out of date, any project-specific options that Dave has to learn, etc etc. It's easy. It's simple. It's portable. Best of all, it's common to every single project out there. 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". 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 use. [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. Now.... granted, the big deficiency of autotools is that sh is not available natively on windows. We have msys, though, which bridges that gap. Cmake ekes out a point here, though, in that it works natively on windows -- assuming you can get the binaries for it. ( NB -- remember, we have plenty of customers that have to for whatever reason compile everything on their system from source... it's usually a security requirement.) Given how well cross compiling works, and given how available msys is, this point on cmake's behalf is small and does not outweigh the big list of minuses. ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
