Marcus D. Hanwell's Blog

I have been experimenting with Qt Creator since the first release. I have always preferred a minimal editor for development work, with my main needs being good syntax highlighting, the ability to switch between different files quickly and something that stays out of my way as much as possible. Previously I had used Vim, Kate and several konsole instances the majority of the time.

Recently I have been looking for something with better integration, and so had been slowly keeping an eye out for a lightweight IDE. My main requirements were something lightweight, good C++ support, ideally good Qt support and CMake integration. Over the weekend I tried the latest Qt Creator 1.1 release and was really impressed.

Seb Ruiz made a great post on Qt Creator 1.1 that summed up many of my thoughts, and gave a quick walkthrough. It was not immediately obvious how to import a CMake project, I was looking for an import project option. All that is necessary is to go to file and open. You can then open the base CMakeLists.txt file for your project and the CMake plugin will do the rest.

From there on in you get great integration with the build system, version control (Git and friends), and your friendly GDB debugger. Under projects you might want to quickly add -j5 (if you are lucky enough to have a quad core machine) to the additional arguments input for make, and select the main executable target for your project if you also have several other executable targets (unit tests etc).

The first time you debug a project you will be prompted to build the Qt debugger helper. Then the integration with GDB really wins over using GDB directly, or using ddd which I had been using more and more recently. I would highly recommend trying Qt Creator if you are looking for a lightweight, cross platform IDE. There are certainly other great IDEs out there, but I think that Qt Creator is a great fit for my development style (and may be yours).

Recently, Luca made a post comparing the speed of CMake and autotools in which some timings were posted. I have to say that I am not sure I agreed with the conclusion and have had a very different experience with the projects I am involved in. As with anything your mileage may vary, and I have not looked at Wesnoth.

I think it is questionable at best to include the time it takes to build CMake, but not autotools. Seems like this is a one time cost and the build time is not that high for either. All tests were performed on my quad core Gentoo box at work. Each step is for the first cold run as would normally be the case when compiling Open Babel from source. The make step used `time make -j5` and I have listed the real time in each case.

The timings are shown in the table below. They seem somewhat similar to the experiences of the QGIS developers who made this move quite some time ago. All times shown are in seconds and are the real time reported by the time command.

For those interested, on this system the total CMake compilation/installation time (cmake-gui disabled) was 1 minute and 54 seconds. The compilation/installation time for automake, autoconf, libtool, m4 was 2 minute and 14 seconds. I am not sure how relevant either of those times are, other than to show neither of them take that long to compile and install. Gentoo users/developers may or may not have CMake installed, most other developers will install the binary packages for either one and are likely to be much more interested in how well it integrates with their development environment, compile and install times.

As a developer I prefer CMake, and have been using/maintaining the CMake based build system for Open Babel for over a year now. It was originally contributed by the KDE Windows porting team, but I found that I spent less time waiting for it to do things when I was working on code too. Add to that the extras CMake comes with, such as CTest, CDash and CPack I think it makes a very attractive option for many projects. I am also hoping that it will allow Open Babel to drop maintaining a totally separate build system for MSVC.

I am sure the Open Babel autotools build system could be optimized (I never tried), but when you add in the additional benefits mentioned above, support for multiple targets such as makefiles, XCode, MSVC, Eclipse etc, one shared language/syntax for all build files and an increasingly polished competitor to autotools, I honestly think it is a sensible choice for projects to move to CMake. There are a few less well known features such as Fortran module dependency parsing that I think are fairly unique and valuable, in scientific coding at least (and I have used the Fortran module dependency parsing at least once and was pleasantly surprised).

Full disclosure: I recently accepted a job offer with Kitware, and will start in the Fall assuming all the visa paperwork falls into place. The opinions expressed here are my own. I think it is great to discuss issues like this objectively, and hope to be a part of making CMake a better build system. As with most software - there are areas that need improving.

Yesterday, on April 1, we tagged and released Avogadro 0.9.3 exactly one calendar month after 0.9.2 was released. This has been quite a big month for Avogadro - I took it to the APS March meeting and the Q-Chem workshop. To the left is a screenshot of the latest release showing the electron density of a vitamin C molecule with the approximated electrostatic surface potential mapped onto it.

We made quite a few fixes and improvements leading up to the APS and Q-Chem meetings. The highlights are in the release notes. Some of my favourites are the animation of molecular vibrations, plotting of IR spectra, improved rendering/handling of surfaces including meshes with colours mapped to their vertices. The Windows build is also fully relocatable, meaning it can even run off of a USB stick. I am hoping to do the same for the Mac and Linux builds too. I made several improvements to the super cell builder, surfaces and even made a start on a z matrix editor (not ready yet).

To the right is the ray traced image of a larger molecule and one of its molecular orbitals. The POV-Ray rendering code has also seen quite a few improvements. I have been experimenting with generating movies from POV-Ray rendered images too. I am planning to make improvements to our build system on Windows and Mac in order to make packaging easier. My main focus is still Linux development, but so many people insist on using other operating systems. Other more exciting things include producing videos of molecules rotating, vibrating, trajectories and using GLSL to improve the rendering performance with big systems (>25,000).

We would appreciate feedback on this release from the wider community. I am really pleased to announce we have gained at least one new contributor this month, David Lonie, who worked on the new IR spectra plotting code. I have made a new ebuild for Gentoo, prepared a Windows installer, Geoff has made a new Mac package and there is ofcourse source. I am sure other distros will have packages ready soon too. Hope you enjoy the graphics - videos to come soon!