Qt-contributors-summit-2011-QtBuildSystem

This roughly covers the session itself and some even less formal face-to-face talks during the summit.

At the session titled ‘Build System’ two use cases of “Building Qt itself” and “Building applications using Qt Creator” were primarily discussed. The case of building Qt applications from the command line was discussed but not emphasized.

For “Building Qt itself” it was noted that –

1. qmake can build Qt 5 now,
2. even if it is not nice, it is there and works,
3. there is no need to change anything for the sake of change only,
4. people do not care much about the process as long as builds Qt.

For “Building applications using Qt Creator” it was noted that –

1. qmake is difficult to control due to its imperative nature,
2. cmake started its life imperative, mixed in declarative constructs for KDE.
3. qmake does not do project configuration (easily),
4. qmake does not cover the actual building (delegated to make/nmake),
5. qmake does not handle deployment/packaging (easily),
6. qmake does not offer cheap “null builds”,
7. qmake can only parallelize build to the degree the make/nmake/ib does it,
8. an existing build system called ‘incredible’ can parallelize builds but is not portable.
9. cmake basically shares all these shortcomings with notable exceptions of configuration.

For “Building applications using a command line tool” it was noted that –

1. while logic from a new build system could be shared across a CLI tool and a IDE (by a common library) the IDE would actively run the logic while a CLI tool explicitly on demand only.
2. there were a lot of Qt Creator developers in the room, leading to the sense that work towards any new build system would probably need to be geared at an IDE.
3. one development strategy for a new build system would involve abstracting code into a library which could be integrated into a command line tool as well.

While some limited discussion was heard of premake, gyp (generate your projects), and wxwidgets build system (not sure about that one), most attention was placed on cmake. Cmake is developed by primarily by Kitware and whose developers are active on mailing lists including Qt. Although some interest was shown by these members regarding this topic, unfortunately none of them were able to attend the summit and seem quite busy.

All in all there was a general feeling of: What is there (both qmake and cmake) sort-of-works, within limits, but is painful to use at times, and the missing/broken parts do not look easily fixable. Starting from scratch looks like an interesting alternative, but would also require a significant amount of work. Some developers are disillusioned with the current state with no clear solution.