[Development] Optional Qt module dependencies (was: RE: qtsystems doesn't compile...)

[Mcgovern Rohan (Nokia-MP-Qt/Brisbane)]

Blasche Alex (Nokia-MP-Qt/Brisbane) said:
> >-----Original Message-----
> >From: development-bounces+alex.blasche=nokia.com at qt-project.org
> >[mailto:development-bounces+alex.blasche=nokia.com at qt-project.org] On
> >Behalf Of ext Rohan McGovern
> 
> >Incidentally it's rather dangerous to do this kind of
> >
> >  contains(QT_CONFIG,some_module):QT+=some_module
> >
> >...behavior nowadays.  In Qt4, QT_CONFIG would be decided at configure
> >time, but in Qt5 it can be changed when you qmake additional modules.
> >
> >In other words, if you test contains(QT_CONFIG,some_module) in your Qt5
> >module, you've made your build behavior implicitly depend on the order in
> >which the user happened to run `qmake' over the qt5 modules, which is
> >largely undefined.  e.g. if you are doing a `make -j20' in qt5.git, the
> >qmakes are also parallelized, and your result might flipflop between
> >builds.
> 
> Surely there must be a way of enforcing dependencies between Qt modules. How would somebody create such a dependency? Is it a matter of mentioning it in sync.profile? Note that the dependency might be platform specific on and currently I don't see a way of specifying it in syn.profile.

Just do

  platform_specific_scope:QT+=some_module

That will give you a big warning if some_module is not available.

IMHO it should be changed into an error, in the meantime that could be
simulated by

  platform_specific_scope:!contains(QT_CONFIG,some_module):error(some_module is required!)
  QT+=some_module

That "enforces" the dependency: either it's available, or the build
fails.  That will be true no matter what weird build procedure might be
used.  Then, to avoid "the build fails":

  - put the dependency in qt.pro so that anyone issuing a `make' in qt5
    will build things in the right order.

  - put the gitmodule name into sync.profile so that the CI scripts know
    to clone that gitmodule for the build.

  - if you are packaging up the qt5 modules using your own packaging
    metadata, then it's your problem to get it right there.

Incidentally I think config tests are overused in various qt5 modules at
the moment - qtsystems for example has 6 config tests, all of them
non-mandatory, doesn't that give 2**6 => 64 possible build
configurations?  Surely it's not intended to actually support them all.