173099696f
With modularized Qt, using QT_CONFIG is dangerous, because the behavior changes depending on the order in which modules are qmake'd. For example, an autotest doing: contains(QT_CONFIG,svg):QT += svg ...will depend on libQtSvg if (and only if) the autotest is qmake'd _after_ qtsvg is qmake'd. This makes the tested functionality unpredictable. Also, if the above example occurs within qtbase, it causes the test to sometimes have a circular dependency: if qtsvg is qmake'd before the test is qmake'd, the test in qtbase depends on qtsvg which depends on qtbase. Tests must avoid functionality tests via QT_CONFIG except where all the tested modules are dependencies of the current module. Usage of QT_CONFIG with qt3support was entirely removed since Qt5 will not retain qt3support. Reviewed-by: Jason McDonald Change-Id: I5a5013b3ec7e1f38fb78864763c9e7586c15e70b
38 lines
879 B
Prolog
38 lines
879 B
Prolog
load(qttest_p4)
|
|
|
|
QT += core-private gui-private
|
|
|
|
SOURCES += tst_qpixmap.cpp
|
|
wince*|symbian: {
|
|
|
|
task31722_0.files = convertFromImage/task31722_0/*.png
|
|
task31722_0.path = convertFromImage/task31722_0
|
|
|
|
task31722_1.files = convertFromImage/task31722_1/*.png
|
|
task31722_1.path = convertFromImage/task31722_1
|
|
|
|
icons.files = convertFromToHICON/*
|
|
icons.path = convertFromToHICON
|
|
|
|
loadFromData.files = loadFromData/*
|
|
loadFromData.path = loadFromData
|
|
|
|
DEPLOYMENT += task31722_0 task31722_1 icons loadFromData
|
|
}
|
|
|
|
wince*: {
|
|
DEFINES += SRCDIR=\\\".\\\"
|
|
DEPLOYMENT_PLUGIN += qico
|
|
} else:symbian {
|
|
LIBS += -lfbscli.dll -lbitgdi.dll -lgdi.dll
|
|
contains(QT_CONFIG, openvg) {
|
|
LIBS += $$QMAKE_LIBS_OPENVG
|
|
QT *= openvg
|
|
}
|
|
} else {
|
|
DEFINES += SRCDIR=\\\"$$PWD\\\"
|
|
win32:LIBS += -lgdi32 -luser32
|
|
}
|
|
|
|
RESOURCES += qpixmap.qrc
|