CMake or not CMake?

I’ve been struggling since I’ve taken the head of the development with the difficulties of debugging the project properly: makefiles, gcc and gdb are really bad tools when you are used to work inside a graphical IDE (in my personal case, Xcode). This seems to be a big problem also for other users: KDevelop project does not seem to work correctly (never used that, but that is what I have been told), which is a big problem when you work on a Qt project and you expect at least to be able to work with the developing suite provided by Qt itself!
A few days ago I meet CMake while I was working on something else: CMake seems to be a great tool, able to generate Makefiles and project files for more or less every IDE and every platform you may think. Even KDE uses it! So I think I’m probably moving to CMake pretty soon, in order to help myself and all those who want to contribute to the project in debugging the code easily.
Do you think it makes sense?

Update [2011.06.07]: I’ve been working with CMake for quite a while, trying its functionalities with small projects first. I finally made the CMake file for Luminance and it seems to be working quite well on Linux and Mac OS X. I’m working on the Windows versione and once I’m sure it works correctly, I will drop the QMake project file (which is currently still part of the repository).

9 Responses to “CMake or not CMake?”

  • CMake is an excellent tool… One thing though: KDevelop is not provided “by Qt” as you stated. You are thinking of QtCreator, the tool provided by Nokia (who also supplies Qt). Consequently, it works excellently with Qt. Eclipse and Netbeans also work well with Qt, and I’d imagine Intellij Idea does as well, although I cannot confirm..

  • I would definitely make the move. Not only can it simplify the build process, and can help people use their preferred development environment, but it makes customisation less of a pain. For example I’m using some extra libs for some optimisations and improvements in the tonemapping operators, and right now, I don’t really like the way I have to hack stuff in the build files to make it configurable. Cmake could make it a question of adding two lines to the CMakeLists.txt. We’re also using cmake at work, to configure and build our projects, and are quite satisfied with it.
    Of course cmake also has her own share of small irritating bugs and gliches, but all in all, it’s a very useful tool.

    • Hi Lator,
      I’m definitely interested in your experience. Would you like to explain me what kind of optimizations you have made to the tonemapping operators?
      I think I’ll make the move soon!

      • Hi!
        As you’ve stated earlier, you removed the openmp directives from the code. While this definitely improves stability, it does make luminance ignore the plus 3 cores in my core i5-2400. So I started profiling the project, to see where to put back some proper, safe multi-threading. I also divide some loops into two or more loops. Having loops, that are designed to handle for example the boundary pixels, and an other loop, to handle the inner pixels. That way, no branching is needed in neither of the loops. While this does not hold significant improvements alone, the speedup is measurable, especially on images of resolution above 1024*768. SSE is an other technology I’m trying to use for some loop unrolling. Also, I have two mid range, CUDA capable graphis cards (in two separate machines…), so I’m playing aroud with OpenCL.
        Only remaining thing is to make some real use of all this, and get some interesting results :) . Of course, if anything makes more then marginal improvement, than I’ll be happy to share the code with the project.

        • I’m really interested in your work. Actually, I’m working in pretty much the same directions: I’ve been looking at the Intel Threading Building Block (TBB) and I think I can try to implement some of the operations with this technology. I had a look at OpenCL as well, but it requires a big effort in changing the structure of some algorithms, otherwise the overhead seems to take over the gain (at least, this seems to be my feeling). Regarding SSE, if you look at the file vex.cpp, you can see that I’ve implemented a lot of vector operations with this technology (and on Linux, where OpenMP is still enabled, the gain is significant).
          Can you write an email to my sourceforge address? I would like to discuss more details with you.
          Best, Davide

  • Hi,

    having worked with CMake for about five years now, there was never a moment regretting the decision. We have been using CMake for a number of user software packages with the LOFAR project; originally confronted with a customized version of the GNU Autotools, decisions such as the one taken by KDE convinced us that picking a more modern tools was definitely the way to go. Sure, as with every new tool some initial learning curve might be necessary (and sadly enough sometimes the documentation could need some work), but there is by far enough resources and examples out there to get going. Especially when targeting a wider range of platforms, CMake has proven to be very powerful. One of the nice by-product is that with CTest and CPack you as get tools for dealing with automated testing and packing.

  • You might want to have a look at “Orc – The Oil Runtime Compiler”; it provides a sort of retargetable assembler language for vectorizing image processing operators (SIMD). It’s used by the free “VIPS” large-image processing library and in some free video codecs.

    Also, regarding KDevelop/QtCreator, there is a huge difference between those two. (In other words, you might really want to have another look at QtCreator.)

    • Actually, I already had a deeper look at QtCreator and I’m using it more often lately: it does work pretty well and once you understand how it is designed, it is a quick tool to work with.
      Regarding ORC, I just wrote you an email. I’m currently looking at different solutions to improve Luminance’s performance and keep the number of dependencies low.

Comments are currently closed.