Re: Getting the real include directories for frameworks?
2015-04-03 10:08 GMT+02:00 Boudewijn Rempt b...@valdyas.org:
I've got a problem porting calligra to kf5 that I don't know how to solve.
We use a 3rd party library called Vc, which does vectorization for us. It
takes a certain object file and builds it for different processor
architecturres. In order to do that, it generates a new gcc line for every
architecture, using the value of INCLUDE_DIRECTORIES, like this:
get_directory_property(_inc INCLUDE_DIRECTORIES)
foreach(_i ${_inc})
list(APPEND _flags -I${_i})
endforeach()
I haven't tested this, but according to the CMake documentation
(http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html)
this strange construction will probably work:
list(APPEND _flags $$BOOL:${_i}:-I$JOIN:${_i}, -I)
Alex
Re: Warning: KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated
2015-02-21 10:02 GMT+00:00 Marco Martin notm...@gmail.com:
Hi all,
As you may have noticed, right now starting plasma is a big spam of
the following error:
Calling KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated,
use KPluginInfo::pluginName() in /whatever/plugin.so instead.
i tried to see where it happens, and seems it's in
ktradeparsetree.cpp , line 30
QVariant ParseContext::property(const QString _key) const
I don't think this properly fixable, since from the stack trace it
seems an appropriate use.. i see two ways to fix it:
1) in ParseContext::property stuf a very long if.. else.. that makes
it call the proper KPluginInfo::correctAccessor() .. but is ugly and
slows it down
2) since this is an appropriate use, consider it not wrong anymore,
and just get rid of the warning.
Opinions? ideas?
I guess most of these would result from a call to
KServiceTypeTrader::self()-query(KMyApp/Plugin,
[X-KDE-PluginInfo-Name] = Foo).
My suggestion would be to add an overload to
KServiceTypeTrader::query() that takes a std::functionbool(const
KPluginInfo) instead of the constraints string.
Ideally we could then deprecate the string based version and use the
std::function version everywhere since that should be safer (and
faster).
KServiceTypeTrader::self()-query(KMyApp/Plugin, [](const
KPluginInfo info) {
return info.property(X-KMyApp-InterfaceVersion).toInt() 15;
}
instead of
KServiceTypeTrader::self()-query(KMyApp/Plugin,
[X-KMyApp-InterfaceVersion] 15);
and then we could also have something like
KServiceTypeTrader::findPlugin(serviceType, name) that expands to
KServiceTypeTrader::self()-query(serviceType, [](const KPluginInfo info) {
return info.pluginName() == name;
}
I have been meaning to add this for quite a while, but I am really
busy at the moment.
Alex
Re: Warning: KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated
2015-02-21 14:43 GMT+00:00 Marco Martin notm...@gmail.com:
On Sat, Feb 21, 2015 at 1:34 PM, Alexander Richardson
arichardson@gmail.com wrote:
and then we could also have something like
KServiceTypeTrader::findPlugin(serviceType, name) that expands to
KServiceTypeTrader::self()-query(serviceType, [](const KPluginInfo info) {
return info.pluginName() == name;
}
I have been meaning to add this for quite a while, but I am really
busy at the moment.
So we would maintain such a warning, but start to port users to that
new api instead?
Yes, that would be my suggestion. I won't be able to work on it before
Thursday though. Ideally there shouldn't be many changes required to
make it work for KMimeTypeTrader aswell, so then in KF5 we can get rid
of all the generated parsing code.
Alex
Re: Another proposal for modernization of our infrastructure
2015-01-31 19:37 GMT+00:00 Christoph Feck cf...@kde.org: On Saturday 31 January 2015 20:07:42 Eike Hein wrote: [...] Qt is using gerrit and we intend to remain a major stakeholde in Qt development, which means a sizable number of KDE developers need to be familiar with gerrit anyway [...] Excuse me, but if KDE developers will have to follow equivalent steps as described at http://qt-project.org/wiki/Setting-up-Gerrit to contribute, then I predict another big loss of developers. I fully agree here! I only now managed to contribute my first patch to Qt because setting up gerrit really scared me. I would have moved on to another project if I hadn't been using+developing KDE for a few years. After having used it now I think gerrit is a great tool but the barrier of entry is just too high. Unless that somehow gets fixed I am strongly in favour of the Phabricator proposal. Alex
Re: desktoptojson and list properties / i18n of JSON files
2014-11-19 16:30 GMT+00:00 Burkhard Lück lu...@hube-lueck.de: Am Mittwoch, 19. November 2014, 01:28:51 schrieb Kevin Funk: On Wednesday 19 November 2014 00:09:25 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Here's one: http://pastebin.kde.org/p4p38fqr1 That's kdevpatchreview.json, generated from kdevpatchreview.desktop via kcoreaddons_desktop_to_json(...) during the CMake run. But the kdevpatchreview.desktop is installed nevertheless and is apparently used to get the translations for Name + Comment/Description. Having german translations for Name + Comment/Description only in kdevpatchreview.json at build time, but removed after installation in the installed kdevpatchreview.desktop file makes them untranslated for me. Looks to me like translations are not supported via json files. Translations are definitively supported with the JSON metadata. kdevpatchreview.desktop is not installed, seems that is a leftover from an older make install. I guess the .desktop file overrides the metadata loaded from the .so file. They both have the same plugin id so the one that is added later (.desktop) overrides the previous one. Regards, Alex
Re: Review Request 121080: Replace KDE_DUMMY_QHASH_FUNCTION.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121080/#review70152 --- When I originally got KF5 to compile on windows I seem to remember having to do this a few times manually as well. Would it make sense to add the macro to KCoreAddons? - Alexander Richardson On Nov. 8, 2014, 11:26 nachm., Andrius da Costa Ribas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121080/ --- (Updated Nov. 8, 2014, 11:26 nachm.) Review request for KDE Base Apps, KDE Frameworks and kdewin. Repository: kde-baseapps Description --- Since we're not using kdemacros.h here anymore, KDE_DUMMY_QHASH_FUNCTION is not available. Implement it instead. Diffs - lib/konq/src/konq_historyentry.h de34d6b Diff: https://git.reviewboard.kde.org/r/121080/diff/ Testing --- It builds (MSVC2013 - 64bit) after this patch (along other patches I'm sending to review today). Kdebase-apps is still not very functional, though (missing icons and weird UI). Thanks, Andrius da Costa Ribas
Re: Review Request 117779: fix crash when textureNode-texture() is null
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/ --- (Updated April 30, 2014, 2:21 p.m.) Status -- This change has been discarded. Review request for kde-workspace and Plasma. Repository: plasma-framework Description --- fix crash when textureNode-texture() is null I get this crash very frequently on my system. This is probably only fixing the symptom and not the underlying issue, however at least plasma no longer crashes every few minutes Diffs - src/declarativeimports/core/windowthumbnail.cpp 59255f75994adb96b30fb503c759b2e9110ab708 Diff: https://git.reviewboard.kde.org/r/117779/diff/ Testing --- No longer crashes Thanks, Alexander Richardson
Review Request 117779: fix crash when textureNode-texture() is null
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/ --- Review request for kde-workspace and Plasma. Repository: plasma-framework Description --- fix crash when textureNode-texture() is null I get this crash very frequently on my system. This is probably only fixing the symptom and not the underlying issue, however at least plasma no longer crashes every few minutes Diffs - src/declarativeimports/core/windowthumbnail.cpp 59255f75994adb96b30fb503c759b2e9110ab708 Diff: https://git.reviewboard.kde.org/r/117779/diff/ Testing --- No longer crashes Thanks, Alexander Richardson
Re: Review Request 117779: fix crash when textureNode-texture() is null
On April 25, 2014, 11:44 p.m., Thomas Lübking wrote: src/declarativeimports/core/windowthumbnail.cpp, line 231 https://git.reviewboard.kde.org/r/117779/diff/1/?file=268344#file268344line231 try before this call. Okay, just thought I'd exit early in that case and not bother with the other stuff. However is this an appropriate fix, or should it be done somewhere else? - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/#review56577 --- On April 25, 2014, 11:41 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/ --- (Updated April 25, 2014, 11:41 p.m.) Review request for kde-workspace and Plasma. Repository: plasma-framework Description --- fix crash when textureNode-texture() is null I get this crash very frequently on my system. This is probably only fixing the symptom and not the underlying issue, however at least plasma no longer crashes every few minutes Diffs - src/declarativeimports/core/windowthumbnail.cpp 59255f75994adb96b30fb503c759b2e9110ab708 Diff: https://git.reviewboard.kde.org/r/117779/diff/ Testing --- No longer crashes Thanks, Alexander Richardson
Re: Review Request 117779: fix crash when textureNode-texture() is null
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117779/ --- (Updated April 26, 2014, 12:51 a.m.) Review request for kde-workspace and Plasma. Repository: plasma-framework Description --- fix crash when textureNode-texture() is null I get this crash very frequently on my system. This is probably only fixing the symptom and not the underlying issue, however at least plasma no longer crashes every few minutes Diffs (updated) - src/declarativeimports/core/windowthumbnail.cpp 59255f75994adb96b30fb503c759b2e9110ab708 Diff: https://git.reviewboard.kde.org/r/117779/diff/ Testing --- No longer crashes Thanks, Alexander Richardson
Re: Review Request 116097: No longer use strlcpy in kstartupconfig
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116097/ --- (Updated March 15, 2014, 3:40 p.m.) Status -- This change has been marked as submitted. Review request for kde-workspace. Repository: kde-workspace Description --- No longer use strlcpy in kstartupconfig This means we no longer need to find libbsd on Linux. kstartupconfig is now uses std::string instead of pure C strings, but the performance difference should be minimal (and it is less error-prone). Diffs - CMakeLists.txt bce3cd1de65b8420a859c342db981919965071ba cmake/modules/FindLibBSD.cmake 6383083023cdbfbeffcab0cef98f48102e593d38 kstartupconfig/CMakeLists.txt ceebd6a65af4cdaa717cfb0dcff5097121cf48d9 kstartupconfig/kstartupconfig.c d8e65f48a75dad49fe6c585f89260c2a6d483809 Diff: https://git.reviewboard.kde.org/r/116097/diff/ Testing --- compiles Thanks, Alexander Richardson
Re: Review Request 116097: No longer use strlcpy in kstartupconfig
On Feb. 26, 2014, 9:32 p.m., Rolf Eike Beer wrote: When you start poking at this code, why not kill the entire fopen/fgets/fixed size buffer stuff and replace it with std streams or something like that? I don't really know what kstartupconfig is supposed to do. This means I don't feel comfortable with touching that code since I could introduce some regressions/behaviour changes. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116097/#review50982 --- On Feb. 26, 2014, 7:11 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116097/ --- (Updated Feb. 26, 2014, 7:11 p.m.) Review request for kde-workspace. Repository: kde-workspace Description --- No longer use strlcpy in kstartupconfig This means we no longer need to find libbsd on Linux. kstartupconfig is now uses std::string instead of pure C strings, but the performance difference should be minimal (and it is less error-prone). Diffs - CMakeLists.txt bce3cd1de65b8420a859c342db981919965071ba cmake/modules/FindLibBSD.cmake 6383083023cdbfbeffcab0cef98f48102e593d38 kstartupconfig/CMakeLists.txt ceebd6a65af4cdaa717cfb0dcff5097121cf48d9 kstartupconfig/kstartupconfig.c d8e65f48a75dad49fe6c585f89260c2a6d483809 Diff: https://git.reviewboard.kde.org/r/116097/diff/ Testing --- compiles Thanks, Alexander Richardson
Review Request 116097: No longer use strlcpy in kstartupconfig
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116097/ --- Review request for kde-workspace. Repository: kde-workspace Description --- No longer use strlcpy in kstartupconfig This means we no longer need to find libbsd on Linux. kstartupconfig is now uses std::string instead of pure C strings, but the performance difference should be minimal (and it is less error-prone). Diffs - CMakeLists.txt bce3cd1de65b8420a859c342db981919965071ba cmake/modules/FindLibBSD.cmake 6383083023cdbfbeffcab0cef98f48102e593d38 kstartupconfig/CMakeLists.txt ceebd6a65af4cdaa717cfb0dcff5097121cf48d9 kstartupconfig/kstartupconfig.c d8e65f48a75dad49fe6c585f89260c2a6d483809 Diff: https://git.reviewboard.kde.org/r/116097/diff/ Testing --- compiles Thanks, Alexander Richardson
Re: Review Request 116097: No longer use strlcpy in kstartupconfig
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116097/ --- (Updated Feb. 26, 2014, 7:11 p.m.) Review request for kde-workspace. Changes --- removed find_package(LibBSD) Repository: kde-workspace Description --- No longer use strlcpy in kstartupconfig This means we no longer need to find libbsd on Linux. kstartupconfig is now uses std::string instead of pure C strings, but the performance difference should be minimal (and it is less error-prone). Diffs (updated) - CMakeLists.txt bce3cd1de65b8420a859c342db981919965071ba cmake/modules/FindLibBSD.cmake 6383083023cdbfbeffcab0cef98f48102e593d38 kstartupconfig/CMakeLists.txt ceebd6a65af4cdaa717cfb0dcff5097121cf48d9 kstartupconfig/kstartupconfig.c d8e65f48a75dad49fe6c585f89260c2a6d483809 Diff: https://git.reviewboard.kde.org/r/116097/diff/ Testing --- compiles Thanks, Alexander Richardson
Re: Review Request 115001: add kf5 namespace to kglobalaccel dbus interface
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115001/#review47338 --- given that the framework installs into KF5GlobalAccel and has the target KF5::GlobalAccel, I would drop the K. - Alexander Richardson On Jan. 13, 2014, 4:51 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115001/ --- (Updated Jan. 13, 2014, 4:51 p.m.) Review request for kde-workspace and Martin Klapetek. Repository: kde-workspace Description --- add kf5 namespace to kglobalaccel dbus interface to prevent files and runtime interfaces overlapping with kdelibs 4 Goes with these reviews for kf5 and kde-runtime https://git.reviewboard.kde.org/r/114999/ https://git.reviewboard.kde.org/r/115000/ Diffs - kcontrol/keys/CMakeLists.txt 072e614 kcontrol/keys/kglobalshortcutseditor.cpp ca11fcd Diff: https://git.reviewboard.kde.org/r/115001/diff/ Testing --- Thanks, Jonathan Riddell
Re: Review Request 113355: Reduce UDSEntry memory usage with implicit sharing
On Oct. 21, 2013, 6:26 p.m., Jan Kundrát wrote:
Have you tried a naive implementation with a
std::vectorstd::pairKey,Value? You say that a typical use case has
eight entries; that's a very small number where a well-tuned vector could
easily beat the O(1) of QHash or the O(log n) of QMap by its O(n)
semantics. Linear scan might very well turn out to be faster due to its
better cache locality and the associated memory streaming benefits. The STL
class has a lower overhead than an implicitly shared QVector (and you do
not need implicit sharing of the actual entries, do you?).
Anyway, the point is, if the number is small enough, the big-O notation
does not necessarily matter.
Milian Wolff wrote:
This is very true. Regarding std::vector not sharing, this is OK since
UDSEntryPrivate _is_ sharing. Also, QString in Field is also shared (and with
this patch actually makes use of this). I'd be interested in the performance
of a (std::)vector/pair approach.
Frank Reininghaus wrote:
I fully agree that big-O is not always the most important thing. However,
kioslaves can in principle add many more than 8 fields to a UDSEntry, and I
had thought that there is a reason why it has always used a QHash.
About the std::vectorstd::pairKey,Value idea: sounds interesting. I
would assume that this approach uses more memory than my current patch though
(if Value == Field). Note that my patch only adds one pointer to the UDSEntry
to keep track of the uint keys (assuming that the QHash is shared with many
UDSEntries), i.e., 8 bytes on a 64 bit system.
In a std::pairuint, Field, you would add a uint to every field of the
entry, and the compiler might actually add some padding to preserve the
alignment of the members of the Field, such that the uint effectively needs
8 bytes for every entry.
Another approach would be to store a QVectorField/std::vectorField
and a separate vector containing the uint keys. A linear scan of the keys
would be much faster if they are all stored next to each other, right? In a
std::vectorstd::pairuint, Field, the different keys would be many bytes
apart.
Jan Kundrát wrote:
Regarding the reason why it has always used a QHash -- this might be
true, or perhaps a programmer used the first thing which came across their
mind. I do this all the time.
You are right on the analysis of the memory consumption -- storing the
keys in the vector (or in the QHash) does have an overhead. The advantage is
that it will save you at least one pointer indirection compared to an
implicitly shared QMap/QHash/... of keys. That might not be a good choice in
this context.
I do not have any numbers comparing performance of a linear scan over a
vectorpair on one hand and a scan of a vectorint. Your idea might or
might not be correct; the memory prefetch in CPUs is known to be an
impressive piece of silicon. It's entirely possible that the speed
improvement of a single vectorint would get neutralized by a missing
prefetch of the target vectorField.
How does your current patch work when you replace a QVector with a
std::vector?
Milian Wolff wrote:
I just thought some more about it and have a potentially even more
performant approach, albeit more complicated code-wise. Food for thought
though:
Just use a std::vectorField, but add the uint (uds field) to Field.
Then encapsulate m_str and m_long in a union and add a bool m_isStr or
similar. I.e.:
struct Field {
// ctors ...
union { // should be sizeof 8
QString m_str;
long long m_long;
};
uint m_uds; // sizeof 4 but would incur a 4byte padding
bool m_isStr; // partially fill padding
};
If I'm not mistaken, this has the same size as the current Field struct.
Then you'd fill this in a std::vector which gets sorted after it is filled by
m_uds. In the lookup functions you can then use binary searches (though at an
estimated size of 8, a simple linear search might perform better).
/me would be interested in the performance of this approach. Note that
you should still keep the QString cache to use implicit sharing there. The
benefit here is that you have _no_ overhead as far as I can see.
Cheers
Frank Reininghaus wrote:
Unfortunately, you cannot put a QString (or any other type with
non-trivial constructor/destructor) into a union. It's easy to see why: when
destructing such an object, how can the compiler know if the 8-byte object
that is stored in the union is the d-pointer of a QString or a long long?
Milian Wolff wrote:
Doh! Of course you are right. Too bad ;-)
Though I do wonder what would happen if one did a
~Field() {
if (m_isStr) {
m_str.~QString();
}
}
Ugly
Re: Review Request 113194: port away from KIcon in libs/taskmanager
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113194/ --- (Updated Oct. 14, 2013, 1:11 p.m.) Status -- This change has been marked as submitted. Review request for kde-workspace. Repository: kde-workspace Description --- port away from KIcon in libs/taskmanager Diffs - libs/taskmanager/abstractgroupingstrategy.cpp 601fcd1d2b186f22d58c9def55fe9ae5b208d7c4 libs/taskmanager/launcherconfig.cpp 8656dad5713eda3d472084d20bc42e372c066389 libs/taskmanager/launcheritem.h 604f046bc4f3a72da9b1f60553ab1802bd251196 libs/taskmanager/launcheritem.cpp 7d8e7af8ad90fc2289d8f897b2177d6f1fb4d5a0 libs/taskmanager/launcherproperties.cpp 5db134b7da7cf89bd269349101258943519a78bc libs/taskmanager/startup.cpp 5524ea23845726b87f1238d9e324bed185399d2a libs/taskmanager/taskactions.cpp b87b3c02e61e9b91966fb2a909bdbd88c9f94a5d libs/taskmanager/taskgroup.cpp 7c8f1f16e322175e8ff0cd117b48311eb5d865f8 Diff: http://git.reviewboard.kde.org/r/113194/diff/ Testing --- compiles Thanks, Alexander Richardson
Review Request 113194: port away from KIcon in libs/taskmanager
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113194/ --- Review request for kde-workspace. Repository: kde-workspace Description --- port away from KIcon in libs/taskmanager Diffs - libs/taskmanager/abstractgroupingstrategy.cpp 601fcd1d2b186f22d58c9def55fe9ae5b208d7c4 libs/taskmanager/launcherconfig.cpp 8656dad5713eda3d472084d20bc42e372c066389 libs/taskmanager/launcheritem.h 604f046bc4f3a72da9b1f60553ab1802bd251196 libs/taskmanager/launcheritem.cpp 7d8e7af8ad90fc2289d8f897b2177d6f1fb4d5a0 libs/taskmanager/launcherproperties.cpp 5db134b7da7cf89bd269349101258943519a78bc libs/taskmanager/startup.cpp 5524ea23845726b87f1238d9e324bed185399d2a libs/taskmanager/taskactions.cpp b87b3c02e61e9b91966fb2a909bdbd88c9f94a5d libs/taskmanager/taskgroup.cpp 7c8f1f16e322175e8ff0cd117b48311eb5d865f8 Diff: http://git.reviewboard.kde.org/r/113194/diff/ Testing --- compiles Thanks, Alexander Richardson
Review Request 108560: Fix kconfigcompiler_test
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108560/ --- Review request for kdelibs. Summary (updated) - Fix kconfigcompiler_test Description (updated) --- Fix kconfigcompiler_test It previously did not find the required files since CMake set TESTSRCDIR wrongly. It was surrounded by quotes and lacking a trailing / This did not cause test failures since QCOMPARE/QVERIFY was not used directly in the test function, so it simply printed messages instead. Diffs (updated) - tier2/kconfig/autotests/kconfig_compiler/CMakeLists.txt 846476a6370ad41b1fbc808e2c738c85042e59a3 tier2/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.h 1be213f5036c03a3ef9347005d5d53e6b440a4d4 tier2/kconfig/autotests/kconfig_compiler/kconfigcompiler_test.cpp f900aaf53de1996213c27357fee5b436ab3c4c8f Diff: http://git.reviewboard.kde.org/r/108560/diff/ Testing (updated) --- Unit test now passes instead of printing messages and failing silently Thanks, Alexander Richardson
Re: Review Request: Fix Solid CMake check with Qt 5
On May 2, 2012, 11:43 a.m., Stephen Kelly wrote: Please do not submit this. It is out of date. You are probably using qt5.git which is way out of date. This is not needed anymore. Ok. How do I get a Qt 5 with which I can build kdelibs? Checkout master in every repo? - Alexander --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104820/#review13267 --- On May 1, 2012, 11:28 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104820/ --- (Updated May 1, 2012, 11:28 p.m.) Review request for kdelibs. Description --- Fix CMake configure with Qt 5 DBusTools is required so that qt5_add_dbus_interfaces is available Not sure if this is the preferred way of solving the issue, but it works for me. Diffs - tier1/solid/src/solid/CMakeLists.txt f309a64 Diff: http://git.reviewboard.kde.org/r/104820/diff/ Testing --- Configuring didn't work before, now it does. Thanks, Alexander Richardson
