FOSDEM '08 is a free and non-commercial event organised by the community, for the community. Its goal is to provide Free and Open Source developers a place to meet.

   

Interview: Bill Hoffman

Thu, 2008-01-17 21:36

Bill Hoffman will give a talk about CMake at FOSDEM 2008.

What do you hope will be the result of your talk?

I hope to gain more visibility for CMake, and to be able to answer any questions people may have, and clear up any misconceptions. Also, I would like to make people aware of the software process that can be achieved with CMake. I also hope to meet other developers and drink some beer!

How did the various sponsors influence CMake's development?

CMake's sponsors have made CMake possible. Starting with National Library of Medicine (NLM), that provided the initial funding for CMake development, and as time went on other customers of Kitware (Sandia National Labs, Los Alamos National Labs and the National Institutes of Health NAMIC project) have provided needed funding for CMake development. Great deals of effort have been spent and continue to be spent on the development of CMake, and without sponsors it would not be possible. So, I would like to thank all of them for their past and continued support we enjoy.

What are the pros and cons of interfacing with native build systems like Make?

The cons are that you can not control everything you would like to. Also, you are subject to bugs in those other build systems. Make is an interesting one, in that it provides very little as it is a simple command line tool. It did allow us to focus on higher level build operations while not having to worry about the lower level details of a make like system. At some point there may be a CBuild that could potentially replace make on some systems.

The more interesting argument on the pro side for interfacing with native build systems are the IDE's like Visual Studio, Xcode, KDevelop, and Eclipse. The big pro is that developers can use the tool they are most efficient with, in a very native way. This allows teams of developers the freedom to choose the build tool that works best for them. At Kitware, there are 40 plus developers collaborating with many other outside groups. There is no single development tool forced on anyone in the company. I use emacs, gnu make and the visual studio compiler. Other developers use Visual Studio projects, and some are not even using the same versions of Visual Studio. Still others at Kitware use Linux or MacOSX. This keeps the developers happy and productive, and avoids forcing people to use things they are not good at.

Being cross-platform and keep being it, is that a difficult goal to reach?

It would be impossible to do without the software development process that we use. By using CMake/CTest/CPack, each night we regression test CMake on every platform that we support. The results are posted to web pages called dashboards. If I break something on a different platform than the one I am developing on, I will usually receive and email within 15 minutes with a link to a page showing me exactly what broke and why.

CMake uses CTest to populate both nightly, continuous, and experimental dashboards for itself. They are publicly available and can be found here.

Each night, the same snapshot of CMake is built on more than 100 computers covering various platforms and configurations. In addition, after almost every commit to the repository, CMake is built and tested on 5 or more machines.

We have a saying "If it's not tested, it doesn't work!". CMake has about 70% code coverage with a large suite of regression tests. When a bug is fixed, we add a test for it.

So the test are covered. What are the other common problems when building large projects?

Performance would be the hardest problem that you face with large projects. The edit/compile/run loop needs to be very fast or developers just can't get things done. Some performance issues just don't show up on smaller projects.

Did CMake benefit from having KDE as a user?

It has benefited greatly from KDE. During the transition many features were added to CMake to support KDE. The installation process became more standard, many performance issues were fixed, progress and color output was added to Make-based builds, and a bunch more features. KDE has also helped to solve the CMake chicken and the egg problem. A project that uses CMake requires CMake to be installed on the machine that is building the software. This requirement has caused some folks to not use CMake. However, if CMake is a standard tool available on systems natively, like the compiler and make, this argument goes away. The use of CMake by KDE has prompted many linux distributions to provide good CMake packages.

How is Kitware doing currently?

Kitware is doing very well, want a job? Kitware is always looking for talented developers to join the team. :) It has been very exciting to watch the company grow from 1 person in 1998 to over 40 in 2008. This March we will be celebrating our 10th year in business.

The impact we have been able to have on the world with our open source tools like CMake, VTK, ITK, ParaView, the Insight Journal and GCC_XML are really amazing given the size of the company. In the end of 2007, we started a computer vision group within Kitware. I think 2008 is going to be a big growth year for the company, and am looking forward to the coming year.