Hi,
Here is a list of things to aim for during the KF5 volunteer day:
1) One of the things we need to remove is all of the use of the Q_WS_*
defines.
git grep Q_WS_
Some of them should be ported to a Q_OS_ define (eg, some of Q_WS_WIN should
be ported to Q_OS_WIN), but *not all of them*, so this can't just be changed
with a script. It should be done manually. Some of them need to be ported to
QPA (lighthouse) in some way.
2) Another thing that should be done is using Find packages from ECM or
CMake.
For example, run 'git grep find_package' in tier1/solid. Some of the results
are provided by CMake, and some come from the local kdelibs/cmake/modules
folder. The kdelibs/cmake/modules folder should not need to be used. For
example find_package(Flex) in solid should be replaced with
find_package(FLEX) which is provided by CMake.
The goal is to be able to run
cd tier1/solid
mkdir build
cd build
cmake ..
make
for each framework.
This is already possible with the itemmodels framework.
It also works with solid, because the packages it searches for are optional
and the FindFoo.cmake files are not found.
3) Remove dependencies from frameworks on kdecore and others.
For example tier1/kdbusaddons depends in some way on Nepomuk:
stephen@hal:~/dev/src/kf5/tier1/kdbusaddons{frameworks}$ git grep -i nepomuk
src/kdbusconnectionpool.cpp: * This file is part of the Nepomuk KDE project.
src/kdbusconnectionpool.cpp:
QString::fromLatin1("NepomukQueryServiceConnection%1").arg(newNumber()) ) )
src/kdbusconnectionpool.h: * This file is part of the Nepomuk KDE project.
4) Find out what should be part of the link interface and what should not
be.
If a framework uses a library, but does not contain any of its symbols in
its API, then it can be linked to privately.
See how this works in kcoreaddons (edited):
target_link_libraries(kcoreaddons
LINK_PUBLIC ${QT_QTCORE_LIBRARY}
LINK_PRIVATE pthread
)
pthread is linked to privately because none of the pthread symbols are in
the kcoreaddons API. That means that if an application links to kcoreaddons
they don't automatically have to link to pthread too.
Conversely, lots of the QtCore API is in the kcoreaddons API (returning
QString, inheriting QObject etc), so downstreams using kcoreaddons also have
to link to QtCore too.
CMake makes things easier for downstreams if we list our public and private
link libraries separately, so we should do that.
The way to figure it out is this:
git grep "QT_.*_LIBRAR"
this gives you the target_link_libraries lines in frameworks.
For example in solid:
stephen@hal:~/dev/src/kf5/tier1/solid{frameworks}$ git grep "QT_.*_LIBRAR"
solid/CMakeLists.txt:target_link_libraries(solid ${QT_QTCORE_LIBRARY}
${QT_QTDBUS_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTGUI_LIBRARY}
${solid_OPTIONAL_LIBS} )
solid/CMakeLists.txt:target_link_libraries(solid LINK_INTERFACE_LIBRARIES
${QT_CORE_LIBRARY} )
solid/CMakeLists.txt:target_link_libraries(solid_static ${QT_QTCORE_LIBRARY}
${QT_QTDBUS_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTGUI_LIBRARY}
${solid_OPTIONAL_LIBS})
tests/CMakeLists.txt:target_link_libraries(fakehardwaretest solid_static
${QT_QTCORE_LIBRARY} ${QT_QTDBUS_LIBRARY} ${QT_QTXML_LIBRARY}
${QT_QTTEST_LIBRARY} )
tests/CMakeLists.txt:target_link_libraries(halbasictest solid_static
${KDEWIN_LIBRARIES} ${QT_QTCORE_LIBRARY} ${QT_QTDBUS_LIBRARY}
${QT_QTXML_LIBRARY} ${QT_QTTEST_LIBRARY} )
tests/CMakeLists.txt:target_link_libraries(solidhwtest ${QT_QTCORE_LIBRARY}
${QT_QTDBUS_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTTEST_LIBRARY} ${LIBS}
solid_static)
tests/CMakeLists.txt:target_link_libraries(solidmttest ${QT_QTCORE_LIBRARY}
${QT_QTDBUS_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTTEST_LIBRARY} ${LIBS}
solid_static)
tests/CMakeLists.txt:#target_link_libraries(solidnettestdbusservice
${QT_QTCORE_LIBRARY} ${QT_QTDBUS_LIBRARY} ${QT_QTXML_LIBRARY}
${QT_QTTEST_LIBRARY})
There are results there for the QtXml and the QtDBus libraries for example.
We can use grep to see if either is in the public API of solid:
stephen@hal:~/dev/src/kf5/tier1/solid{frameworks}$ git grep Xml
solid/backends/fakehw/fakemanager.cpp:#include <QtXml/QDomDocument>
solid/backends/fakehw/fakemanager.cpp:#include <QtXml/QDomElement>
solid/backends/fakehw/fakemanager.cpp:#include <QtXml/QDomNode>
solid/backends/fakehw/fakemanager.cpp: QString machineXmlFile = xmlFile;
solid/backends/fakehw/fakemanager.cpp: d->xmlFile = machineXmlFile;
solid/managerbase.cpp: QString
solidFakeXml(QString::fromLocal8Bit(qgetenv("SOLID_FAKEHW")));
solid/managerbase.cpp: if (!solidFakeXml.isEmpty()) {
solid/managerbase.cpp: m_backends << new
Solid::Backends::Fake::FakeManager(0, solidFakeXml);
stephen@hal:~/dev/src/kf5/tier1/solid{frameworks}$ git grep Dom
solid/backends/fakehw/fakemanager.cpp:#include <QtXml/QDomDocument>
solid/backends/fakehw/fakemanager.cpp:#include <QtXml/QDomElement>
solid/backends/fakehw/fakemanager.cpp:#include <QtXml/QDomNode>
solid/backends/fakehw/fakemanager.cpp: QDomDocument fakeDocument;
solid/backends/fakehw/fakemanager.cpp: qWarning() << Q_FUNC_INFO <<
"Error while creating the QDomDocument." << endl;
solid/backends/fakehw/fakemanager.cpp: QDomElement mainElement =
fakeDocument.documentElement();
solid/backends/fakehw/fakemanager.cpp: QDomNode node =
mainElement.firstChild();
solid/backends/fakehw/fakemanager.cpp: QDomElement tempElement =
node.toElement();
solid/backends/fakehw/fakemanager.cpp:FakeDevice
*FakeManager::parseDeviceElement(const QDomElement &deviceElement)
solid/backends/fakehw/fakemanager.cpp: QDomNode propertyNode =
deviceElement.firstChild();
solid/backends/fakehw/fakemanager.cpp: QDomElement propertyElement =
propertyNode.toElement();
solid/backends/fakehw/fakemanager.h:class QDomElement;
solid/backends/fakehw/fakemanager.h: FakeDevice *parseDeviceElement(const
QDomElement &element);
QtXml is only an implementation detail of solid, so we can link to it
privately. Repeat for all link dependencies. If you can say for certain that
one or some arguments to link_interface_libraries should be public, then go
ahead and change them to use the LINK_PUBLIC and LINK_PRIVATE keywords.
If in doubt, put what you are not certain about after LINK_PRIVATE.
Thanks,
Steve.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
