Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

Qt-contributors-summit-2011-QtBuildSystem: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
m (Categorize)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
[[Category:QtCS2011]]
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 –
# qmake can build Qt 5 now,
# even if it is not nice, it is there and works,
# there is no need to change anything for the sake of change only,
# people do not care much about the process as long as builds Qt.
For "Building applications using Qt Creator" it was noted that –
# qmake is difficult to control due to its imperative nature,
# cmake started its life imperative, mixed in declarative constructs for <span class="caps">KDE</span>.
# qmake does not do project configuration (easily),
# qmake does not cover the actual building (delegated to make/nmake),
# qmake does not handle deployment/packaging (easily),
# qmake does not offer cheap "null builds",
# qmake can only parallelize build to the degree the make/nmake/ib does it,
# an existing build system called 'incredible' can parallelize builds but is not portable.
# cmake basically shares all these shortcomings with notable exceptions of configuration.
For "Building applications using a command line tool" it was noted that –
# while logic from a new build system could be shared across a <span class="caps">CLI</span> tool and a <span class="caps">IDE</span> (by a common library) the <span class="caps">IDE</span> would actively run the logic while a <span class="caps">CLI</span> tool explicitly on demand only.
# 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 <span class="caps">IDE</span>.
# 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.

Latest revision as of 16:48, 6 January 2017

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

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.