On 23 juin 2016, at 09:29, Lars Knoll <lars.kn...@qt.io> wrote: > Hi, > > As some of you might know, I’ve been working for some time now on developing > a new configuration system for Qt. As the first large change went in > yesterday evening, I guess it’s time I describe it a little, and also tell > you a bit about what’s still coming. > > The goal of the new system is twofold. First of all, we are seeing a large > need, especially with our embedded users, to customise how Qt is being built. > Many of them have size restrictions ore rather hard testing requirements, > where being able to limit the functionality available in Qt is extremely > helpful. We had such a system (see src/corelib/global/qfeatures.txt) before, > but it was disconnected from the configure script, wasn’t really maintained > since Qt 4 times, and had quite many limitations that I hope to solve with > the new system. > > Secondly, we have had to deal for a long time with two different > configuration systems. We had a monster of a shell script for unix, and an Qt > based executable on Windows. Changes to Qt often required changing both, and > it was very easy to sneak subtle errors in. Maintainability of the old system > was in general very poor. > > So with that comes the new system. As I said, the first (but largest) patch > went yesterday evening (see https://codereview.qt-project.org/#/c/149202/). > It basically moves most of the configuration handling from the shell script > over to a declarative json file (currently configure.json) that is being > processed by qmake. This currently only affects Unix, Windows platforms are > still being configured through configure.exe. The change aims to be a 1 to 1 > (or at least as close as possible) mapping of the old shell script to the new > system. So if you find that some configuration you’re using is suddenly > broken let me know. > > I’ll send out a separate email describing the new system in more detail for > those who are interested. > > For everybody else, there are a couple of changes that will still come in > over the next couple of weeks: > > * Give every module a qtmoduleglobal.h and qtmoduleglobal_p.h file > > We already have per module global files for many modules (they are often > required for the export/import handling of classes/symbols). With the new > system we will add a public and private global file per module. I’ll start > requiring that all public headers of the module include the public global > file first, all private headers the private global file. > > This is needed some steps below to modularise the configuration system and to > allow us to track whether a certain feature we rely upon in code is actually > available or not. > > See https://codereview.qt-project.org/#/c/161143 and subsequent changes (the > change adding global_p.h is still missing here, but will come as well) > > * Saner handling of 3rd party libs > > Currently all our dependencies to external libs are handled in a rather > ad-hoc way in the pro files. The goal is to unify this, see > https://codereview.qt-project.org/#/c/161660/ > > * Modularisation of the new configuration system > > I have some patches pending to modularise the new system. We will basically > have one json configuration file per module/shared library. This will also > allow us to use the system fully on repositories outside of qtbase, who > currently have rather limited support for being configured. > > With this change, we will start creating a qtmodule-config.h and > qtmodule-config_p.h file as well as a corresponding public and private .pri > files for each module. qtmodule-config.h will get included from the public > global header for the module, qtmodule-config_p.h from the private one. > > The public pro file will contain definitions for the features that are being > exported by the module, the private one for features that are only relevant > in the context of the module itself. As an example, ‘mimetypes’ would be a > public feature of QtCore (as it changes the set of available API), whereas > ‘glib’ would be most likely a private one (as it only determines which event > loop to use and doesn’t change API). > > See change https://codereview.qt-project.org/#/c/159604/40 and the following > commit > > * Integration of the old feature system > > As said above, there is the old feature system (see qfeatures.txt in > corelib/global). With the work above done, integrating it into the system > will be trivial (change https://codereview.qt-project.org/#/c/159763/) > > * With this done, I will also want to introduce a new mechanism to handle > features in our cpp and header files. The current double negated #ifndef > QT_NO_FOO is hard to read and unsafe. By unsafe, I mean that the compiler > won’t error out or warn us if the feature ‘foo’ isn’t available (because of a > typo or because the feature is actually defined in widgets and you tried > using it in gui). I have some pending work that would change this to use a > macro function "#if QT_HAS_FEATURE(foo)” where we would actually get a > compile error if the feature foo isn’t known to the system. As a nice side > effect I’m planning on having the same names for features between .pro and > c++ files. > > * Further reduce the shell script > > The longer term goal will be to reduce the shell script further, until it’s > basically a bootstrapping step for qmake, and hand all the other > configuration work over to qmake. Some more patches for this are pending, but > further help here would be appreciated. > > > * Get rid of configure.exe > > Finally, I’d also like to get rid of configure.exe, and do the same thing on > Windows (ie. Bootstrap qmake from a small script, like we bootstrap > configure.exe today) and then let qmake deal with the rest. With that we > should be able to get to one cross-platform configuration system. For this > task I’d be looking for volunteers :) > > Cheers, > Lars >
Hi, Pretty nice ! That will be very useful to simplify Qt customization for constrained hardware. Will there also be a GUI available to help create custom configurations ? A side question, I've got a few submissions adding handling for a bunch of missing QT_NO_DRAGANDDROP/CLIBOARD tests. Should I ping them to get them in before the QT_HAS_FEATURE migration or rather wait for it and update the patches then ? Regards Samuel
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
