Russel Winder wrote: > On Fri, 2010-10-08 at 21:41 +0200, Jens Mueller wrote: > > > For C, C++, Fortran, and hence D, I personally find CMake awkward and > > > clumsy. > > > > I also think CMake isn't that shiny. But you can get the job done once > > you're familiar with it. And it has been adopted by some big projects: > > Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see > > http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake). > > That should be put into consideration. > > Well KDE was about to choose bksys (the immediate ancestor of Waf) until > some nasty politiking went on and all of a sudden they chose CMake. I > don't know all the details, but I know enough to say that that decision > was not made based on a proper study. > > SCons is used by Intel for most of their software products, especially > the parallel tools suite, also by id Games for all their products. > Simply listing users of a product is a "pissing contest" and not at all > helpful. If you choose a tool that many others have chosen and are > happy with then fine, you get the comfort of not being on your own -- > and that is a good thing. However, an individuals or organizations > actual needs may mean that using something not chosen by the herd is far > more beneficial.
My point is only that CMake works for big projects. Which makes a strong argument. If you run into a problem you can very likely check out how they did it. However they ended up with it, it seems to do its job. But of course if other tools can handle this equally good you need to go beyond that. > > I never used this but CMake has generators for Visual Studio and through > > the Makefile Generators you can integrate it in CodeBlocks and Eclipse. > > Don't know how important this is. I live happily with the generated > > Makefiles. > > SCons can likewise generate Visual Studio project files. SCons can be > used directly in Eclipse so no need for Makefile generation. That's nice. > > I have to admit I neither know Scons nor Waf. Maybe these are superior. > > They're Python-based, right? I'll guess that makes them favorable for > > Python programmers. > > SCons and Waf are both Python systems that have an internal DSL for > describing the build. Both have the classic two phase operation: read > the files and build the DAG describing the project and build; analyse > the filestore and spawn tasks in order to reconcile the actual filestore > with the required filestore. (Actually 'filestore' is a variable here, > you an target things other than the filestore, but its usually the > filestore being processed.) > > Using Python (or any other dynamic language I would suspect, cf Rake, > Rant using Ruby) is a big win, certainly over m4 macros. CMake has its > own language which is part way to being Lisp but has lots of quirks and > idiosyncrasies such that if they had just used a Lisp interpreter, > things would be a lot better. I agree. It's not a nice solution. Maybe they are just known because a company supports it and puts some effort into it. But in the long run maybe others will take over because of better design. > > On top of my head some things I find nice in CMake. Just curious whether > > Scons/Waf have similar features. > > * Find Google Test/other libraries (if supported) in one line: > > find_package(GTest REQUIRED) > > Waf and SCons can both do this but it is not packaged as a one liner in > this form. The issue is how the dependencies are packaged up in order > to create. CMake has one route, Waf one route and SCons a slightly > different route. CMake looks good on this point but Waf and SCons are > not poor in comparison. How do you do this with Waf/Scons? Best solution to me is: Somebody writes a module for finding a library and this module is distributed with the tool. The user only needs to include the module. > > * Tight integration for testing and packaging (ctest, cpack) > > Somewhat unfair to appear to name CTest and CPack as requirements as > they are are Kitware products integrated into CMake ;-) Waf and SCons > both have infrastructure for supporting tests, they are just called > something different than CTest and CPack Just wanted to mention that you can test and package your software. I'm not here to disqualify any other tool. Just want to say what you can do with CMake and what seems important to me. > > * Publishing build/test results > > Isn't that the job of the continuous integration server? Depends. I know of a C++ project that uses CMake. Before they ship a new release they need to make sure that the building and testing pass. On their mailing list the maintainer announces that she likes to ship a new version and says something like: We want to support these compilers and those platforms. Since each developer has a different development setup they just run the tests locally and publish them to a central board. One after the other the developers post their results. I find this quite nice for distributed/Open Source development. Decoupling the testing and publishing. Of course you can setup your own machine that tests all of these different configurations. With Hudson it seems to me that there is one central point that does the integration. Maybe they allow some distribution. Just wanted to point out that I find this separation/distribution useful. > > * No dependencies besides a C++ compiler for installation. > > CMake requires cmake, make, bash, etc. in addition to the compilation > tool chain which is usually more than just the compiler. Oh yes. You're absolutely right. I forgot to think about those because they are usually there. I shouldn't take them for granted. > Waf and SCons both require a Python installation, but that is > increasingly standard now. No need for Bash or Make, but you do need > exactly the same toolchain otherwise. Right. > > * Continuous Integration watching subversion repository > > Why Subversion explicitly, it is so last century :-) Bazaar, Mercurial > and Git are the "go to" version control systems these days. Even if you > have a Subversion central repository, you use Bazaar, Mercurial or Git > as your client. Well I do anyway! > > Actually I am not sure what you mean by this. CI is usually these days > either Buildbot or Hudson I think the new century version control systems are supported as well. Don't know to what extent though. What is CI in the end. It's get me that the software out of the repository and build/test it and publish results. I would break this into (at least) two steps building/testing and publishing. For example I tend to forget running the tests before committing. So I set it up to watch my personal repository. It does building and testing for me but does not publish the results. If it fails it can give me some local feedback. This way I automatically make sure that I broke nothing. As I said that's something I tend to forget. To sum up I'm arguing for having some kind of local integration. And Hudson is nothing like some special kind of this. I mean I could setup a local Hudson. But isn't it nice to have all what's needed coming with the sources. Everybody can do the integration for their system configuration(s) himself. See for example http://my.cdash.org/index.php?project=libarchive http://my.cdash.org/index.php?project=Teem http://my.cdash.org/index.php?project=CTK&display=project > > * Valgrind/Purify integration > > I believe both have this but I don't know, in my C++ programming I never > use these tools. Seems so. Jens
