[Development] New configuration system

[Samuel Gaist]

On 23 juin 2016, at 09:29, Lars Knoll <Lars.Knoll at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160702/3dbb615f/attachment.sig>