Robin Burchell said: > 2011/11/1 Thiago Macieira <[email protected]>: > > I cannot find this mandatory dependency. If it's open, can someone share the > > link to where it can be found? If it's not open, please disable this > > functionality. > > I guess this might be a consequence of qtjsondb becoming available: > > !contains(QT_CONFIG, jsondb): { > PRIVATE_HEADERS += qscreensaver_linux_p.h > SOURCES += qscreensaver_linux.cpp > > DEFINES += QT_NO_JSONDB > } else { > PRIVATE_HEADERS += qjsondbwrapper_p.h \ > qscreensaver_jsondb_p.h > > SOURCES += qjsondbwrapper.cpp \ > qscreensaver_jsondb.cpp > > QT += jsondb > PKGCONFIG += mtcore > LIBS += -L$$[QT_INSTALL_PREFIX]/opt/mt/lib -lmtcore > -Wl,-rpath,$$[QT_INSTALL_PREFIX]/opt/mt/lib > } > > Whoever maintains this, you should probably change that contains() > conditional to also check packagesExist(mtcore).
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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
