Blasche Alex (Nokia-MP-Qt/Brisbane) said:
> >-----Original Message-----
> >From: [email protected]
> >[mailto:[email protected]] 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.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
