Something for the weekend

Stephen Kelly steveire at gmail.com
Fri Feb 17 16:00:03 UTC 2012


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 at 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 at 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 at 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 at 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.







More information about the Kde-frameworks-devel mailing list