Review Request 113851: Unbreak kauth-policy-gen
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113851/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- This is a two-commit patch, it fixes a build failure in kde-workspace/kcontrol/dateandtime. 1. make policy-gen accept a second argument pointing to the output file 2. Unbreak call to kauth-policy-gen Uses the new kauth-policy-gen syntax for extra safety (no empty output file gets created in case of failure) Note: I haven't tested the Mac part of the code. Would be awesome if someone could give it a try. Diffs - tier2/kauth/src/policy-gen/policy-gen.cpp b00e09f tier2/kauth/KAuthConfig.cmake.in 67eb7de tier2/kauth/cmake/KAuthMacros.cmake 1ebc889 tier2/kauth/src/CMakeLists.txt 68c7c37 Diff: http://git.reviewboard.kde.org/r/113851/diff/ Testing --- Still builds, kcmclock_actions.policy is correctly generated in kde-workspace/kcontrol/dateandtime Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113851: Unbreak kauth-policy-gen
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113851/ --- (Updated Nov. 14, 2013, 10:38 a.m.) Review request for KDE Frameworks. Changes --- --trailing-space Repository: kdelibs Description --- This is a two-commit patch, it fixes a build failure in kde-workspace/kcontrol/dateandtime. 1. make policy-gen accept a second argument pointing to the output file 2. Unbreak call to kauth-policy-gen Uses the new kauth-policy-gen syntax for extra safety (no empty output file gets created in case of failure) Note: I haven't tested the Mac part of the code. Would be awesome if someone could give it a try. Diffs (updated) - tier2/kauth/KAuthConfig.cmake.in 67eb7de tier2/kauth/cmake/KAuthMacros.cmake 1ebc889 tier2/kauth/src/CMakeLists.txt 68c7c37 tier2/kauth/src/policy-gen/policy-gen.cpp b00e09f Diff: http://git.reviewboard.kde.org/r/113851/diff/ Testing --- Still builds, kcmclock_actions.policy is correctly generated in kde-workspace/kcontrol/dateandtime Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113851: Unbreak kauth-policy-gen
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113851/ --- (Updated Nov. 14, 2013, 10:43 a.m.) Review request for KDE Frameworks and Dario Freddi. Repository: kdelibs Description --- This is a two-commit patch, it fixes a build failure in kde-workspace/kcontrol/dateandtime. 1. make policy-gen accept a second argument pointing to the output file 2. Unbreak call to kauth-policy-gen Uses the new kauth-policy-gen syntax for extra safety (no empty output file gets created in case of failure) Note: I haven't tested the Mac part of the code. Would be awesome if someone could give it a try. Diffs - tier2/kauth/KAuthConfig.cmake.in 67eb7de tier2/kauth/cmake/KAuthMacros.cmake 1ebc889 tier2/kauth/src/CMakeLists.txt 68c7c37 tier2/kauth/src/policy-gen/policy-gen.cpp b00e09f Diff: http://git.reviewboard.kde.org/r/113851/diff/ Testing --- Still builds, kcmclock_actions.policy is correctly generated in kde-workspace/kcontrol/dateandtime Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kdelibs_frameworks_qt5 #1671
See http://build.kde.org/job/kdelibs_frameworks_qt5/1671/changes Changes: [jr] add trailing slash to fix list() -- [...truncated 5630 lines...] Linking CXX shared module emoticonstheme_xmpp.so [ 64%] Built target klanguagebuttontest [ 65%] Building CXX object tier3/kiconthemes/src/CMakeFiles/KIconThemes.dir/kiconloader.cpp.o Linking CXX executable kcolorutilsdemo Scanning dependencies of target emoticonstheme_adium Scanning dependencies of target emoticonstheme_pidgin [ 65%] [ 65%] Building CXX object tier3/kemoticons/src/providers/adium/CMakeFiles/emoticonstheme_adium.dir/adium_emoticons.cpp.o Building CXX object tier3/kemoticons/src/providers/pidgin/CMakeFiles/emoticonstheme_pidgin.dir/pidgin_emoticons.cpp.o Linking CXX shared module emoticonstheme_kde.so http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp: In member function ‘void KIconLoaderPrivate::_k_refreshIcons(int)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:466:22: warning: ‘void KIconLoader::newIconLoader()’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.h:459) [-Wdeprecated-declarations] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp: In function ‘QIcon DesktopIconSet(const QString, int)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1540:70: warning: ‘QIcon KIconLoader::loadIconSet(const QString, KIconLoader::Group, int, bool)’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1512) [-Wdeprecated-declarations] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp: In function ‘QIcon BarIconSet(const QString, int)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1555:72: warning: ‘QIcon KIconLoader::loadIconSet(const QString, KIconLoader::Group, int, bool)’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1512) [-Wdeprecated-declarations] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp: In function ‘QIcon SmallIconSet(const QString, int)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1570:70: warning: ‘QIcon KIconLoader::loadIconSet(const QString, KIconLoader::Group, int, bool)’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1512) [-Wdeprecated-declarations] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp: In function ‘QIcon MainBarIconSet(const QString, int)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1585:76: warning: ‘QIcon KIconLoader::loadIconSet(const QString, KIconLoader::Group, int, bool)’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1512) [-Wdeprecated-declarations] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp: In function ‘QIcon UserIconSet(const QString)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1600:57: warning: ‘QIcon KIconLoader::loadIconSet(const QString, KIconLoader::Group, int, bool)’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1512) [-Wdeprecated-declarations] In file included from http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1667:0: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/build/tier3/kiconthemes/src/moc_kiconloader.moc: In static member function ‘static void KIconLoader::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/build/tier3/kiconthemes/src/moc_kiconloader.moc:191:35: warning: ‘void KIconLoader::newIconLoader()’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/kiconthemes/src/kiconloader.cpp:1639) [-Wdeprecated-declarations] [ 65%] Building CXX object tier3/kiconthemes/src/CMakeFiles/KIconThemes.dir/kicontheme.cpp.o Scanning dependencies of target kemoticontest [ 65%] Building CXX object tier3/kemoticons/src/providers/adium/CMakeFiles/emoticonstheme_adium.dir/emoticonstheme_adium_automoc.cpp.o [ 65%] Building CXX object tier3/kemoticons/autotests/CMakeFiles/kemoticontest.dir/kemoticontest.cpp.o [ 65%] Linking CXX shared module emoticonstheme_adium.so Building CXX object tier3/kemoticons/src/providers/pidgin/CMakeFiles/emoticonstheme_pidgin.dir/emoticonstheme_pidgin_automoc.cpp.o [ 65%] Built target kconfigdialog_unittest [ 65%] Building CXX object
Jenkins build is back to normal : kdelibs_frameworks_qt5 #1672
See http://build.kde.org/job/kdelibs_frameworks_qt5/1672/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113851: Unbreak kauth-policy-gen
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113851/#review43658 --- After applying this patch, kde-workspace builds with clean install dir for me on opensuse. - Bhushan Shah On Nov. 14, 2013, 3:13 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113851/ --- (Updated Nov. 14, 2013, 3:13 p.m.) Review request for KDE Frameworks and Dario Freddi. Repository: kdelibs Description --- This is a two-commit patch, it fixes a build failure in kde-workspace/kcontrol/dateandtime. 1. make policy-gen accept a second argument pointing to the output file 2. Unbreak call to kauth-policy-gen Uses the new kauth-policy-gen syntax for extra safety (no empty output file gets created in case of failure) Note: I haven't tested the Mac part of the code. Would be awesome if someone could give it a try. Diffs - tier2/kauth/KAuthConfig.cmake.in 67eb7de tier2/kauth/cmake/KAuthMacros.cmake 1ebc889 tier2/kauth/src/CMakeLists.txt 68c7c37 tier2/kauth/src/policy-gen/policy-gen.cpp b00e09f Diff: http://git.reviewboard.kde.org/r/113851/diff/ Testing --- Still builds, kcmclock_actions.policy is correctly generated in kde-workspace/kcontrol/dateandtime Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113847: Remove unnecessary dependency in dnssd
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113847/#review43663 --- This review has been submitted with commit fc78af7548938ee32f523b2a8b3ea750f6bda7ca by Michael Palimaka to branch frameworks. - Commit Hook On Nov. 13, 2013, 5:53 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113847/ --- (Updated Nov. 13, 2013, 5:53 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- I cannot find any reference to QtWidgets, so there's no point trying to find it. Diffs - tier2/dnssd/CMakeLists.txt 13497d199be73c0d6ce3038005543837311f46e5 Diff: http://git.reviewboard.kde.org/r/113847/diff/ Testing --- Builds with QtWidgets not installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113847: Remove unnecessary dependency in dnssd
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113847/ --- (Updated Nov. 14, 2013, 1:57 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- I cannot find any reference to QtWidgets, so there's no point trying to find it. Diffs - tier2/dnssd/CMakeLists.txt 13497d199be73c0d6ce3038005543837311f46e5 Diff: http://git.reviewboard.kde.org/r/113847/diff/ Testing --- Builds with QtWidgets not installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113845: Remove unnecessary dependencies in kauth
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113845/ --- (Updated Nov. 14, 2013, 2:02 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- There is no reference to QtConcurrent, or QtTest outside of autotests, so there's no need to search for it (QtTest is still pulled in autotests/). Diffs - tier2/kauth/CMakeLists.txt 86462232d0ffb4d8e1f42600da627e0e26e308af Diff: http://git.reviewboard.kde.org/r/113845/diff/ Testing --- Builds and passes tests with QtConcurrent not installed. Non-test components build without having QtTest installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113845: Remove unnecessary dependencies in kauth
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113845/#review43664 --- This review has been submitted with commit 2a5fb637a595d38a9f556654234cbfcc166ee0d9 by Michael Palimaka to branch frameworks. - Commit Hook On Nov. 13, 2013, 5:33 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113845/ --- (Updated Nov. 13, 2013, 5:33 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- There is no reference to QtConcurrent, or QtTest outside of autotests, so there's no need to search for it (QtTest is still pulled in autotests/). Diffs - tier2/kauth/CMakeLists.txt 86462232d0ffb4d8e1f42600da627e0e26e308af Diff: http://git.reviewboard.kde.org/r/113845/diff/ Testing --- Builds and passes tests with QtConcurrent not installed. Non-test components build without having QtTest installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113860: Improve dependency specification in karchive
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113860/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- QtTest is already pulled in autotests/, so there's no need to require it in the root too. Diffs - tier1/karchive/CMakeLists.txt 3e5ac47d6ff82451ecaa339d5bb708a868713400 Diff: http://git.reviewboard.kde.org/r/113860/diff/ Testing --- Builds with QtTest not installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113861: use ecm_mark_as_test instead of kde4_add_unit_test in kwin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113861/ --- Review request for KDE Frameworks and Martin Gräßlin. Repository: kde-workspace Description --- summary says all Diffs - kwin/tests/CMakeLists.txt 0e2bab9 Diff: http://git.reviewboard.kde.org/r/113861/diff/ Testing --- compiles, tests pass Thanks, Bhushan Shah ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113862: Improve dependency specification in kcodecs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113862/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- QtTest is only required by autotests, so only look for it there. Diffs - tier1/kcodecs/CMakeLists.txt b2876079d05aa9d0c6c29509c2b1251668578a22 tier1/kcodecs/autotests/CMakeLists.txt eca443fa80cd514ac4fe70830c9993f233a33738 Diff: http://git.reviewboard.kde.org/r/113862/diff/ Testing --- Framework builds with QtTest not installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113861: use ecm_mark_as_test instead of kde4_add_unit_test in kwin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113861/#review43671 --- Ship it! Ship It! - Martin Gräßlin On Nov. 14, 2013, 3:53 p.m., Bhushan Shah wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113861/ --- (Updated Nov. 14, 2013, 3:53 p.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kde-workspace Description --- summary says all Diffs - kwin/tests/CMakeLists.txt 0e2bab9 Diff: http://git.reviewboard.kde.org/r/113861/diff/ Testing --- compiles, tests pass Thanks, Bhushan Shah ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113861: use ecm_mark_as_test instead of kde4_add_unit_test in kwin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113861/ --- (Updated Nov. 14, 2013, 3:34 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Martin Gräßlin. Repository: kde-workspace Description --- summary says all Diffs - kwin/tests/CMakeLists.txt 0e2bab9 Diff: http://git.reviewboard.kde.org/r/113861/diff/ Testing --- compiles, tests pass Thanks, Bhushan Shah ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113861: use ecm_mark_as_test instead of kde4_add_unit_test in kwin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113861/#review43674 --- This review has been submitted with commit 659ee81a092a7efe0e56544277f9863485a3dec7 by Bhushan Shah to branch master. - Commit Hook On Nov. 14, 2013, 2:53 p.m., Bhushan Shah wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113861/ --- (Updated Nov. 14, 2013, 2:53 p.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kde-workspace Description --- summary says all Diffs - kwin/tests/CMakeLists.txt 0e2bab9 Diff: http://git.reviewboard.kde.org/r/113861/diff/ Testing --- compiles, tests pass Thanks, Bhushan Shah ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113683: Fix kdeclarative standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113683/ --- (Updated Nov. 14, 2013, 3:56 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: kdelibs Description --- Make kdeclarative build standalone. Do I need to add the dependencies of all dependencies as well now? Diffs - superbuild/CMakeLists.txt 56e17dd42a8cc2b2c8a0015c7c5ec74902e0bd3e tier3/kdeclarative/CMakeLists.txt 1f23914a0ba65982c7b597e92fe9c9e920e2abe6 Diff: http://git.reviewboard.kde.org/r/113683/diff/ Testing --- Builds. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113683: Fix kdeclarative standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113683/#review43677 --- This review has been submitted with commit 934008a4684befba40cdc50ff4b81682dd03a05f by Maarten De Meyer to branch frameworks. - Commit Hook On Nov. 12, 2013, 7:52 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113683/ --- (Updated Nov. 12, 2013, 7:52 p.m.) Review request for KDE Frameworks, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: kdelibs Description --- Make kdeclarative build standalone. Do I need to add the dependencies of all dependencies as well now? Diffs - superbuild/CMakeLists.txt 56e17dd42a8cc2b2c8a0015c7c5ec74902e0bd3e tier3/kdeclarative/CMakeLists.txt 1f23914a0ba65982c7b597e92fe9c9e920e2abe6 Diff: http://git.reviewboard.kde.org/r/113683/diff/ Testing --- Builds. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On 10.11.2013 18:27, Kevin Ottens wrote:
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding folders
in header files.
I think there's an aspect missing in your proposal. There's the
convention we want for #include and where we install. That's in the
end two different things even though related.
I think, that for all the frameworks, headers should be installed in:
$PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and the
convenience camel case ones. If we go for that, we get something
consistent install wise and easy to deal with. Then the distinction
you make below is just about the include path we want when someone
pulls a framework in.
I think the consensus is there should be two different situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then
headers should be installed in include and convenience headers
should
be installed in include/KDE.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then both
$PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are
added
in the include path, thus supporting the #include kfoo.h and
#include KFoo styles.
To support #include kfoo.h and #include KFoo you only need to have
$PREFIX/include/KF5/FrameworkName/ in the include path. Adding
$PREFIX/include/KF5/ would add support for
#include FrameworkName/kfoo.h and #include FrameworkName/KFoo.
Do we want to support this as well? (I have no strong opinion on this
topic)
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they
should
be installed in include/{lowercaseframework} and convenience headers
should be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then only
$PREFIX/include/KF5/ is added in the include path, thus supporting
the
#include FrameworkName/foo.h and #include FrameworkName/Foo
styles.
Some special files should still go in include:
{lowercaseframework}_export.h {lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I agree.
Wouldn't it be more self-contained to have those in
$PREFIX/include/KF5/FrameworkName as well?
After all, those includes are mostly internal, so they should not be
the
first files you meet if you wander in $PREFIX/include/KF5 IMO.
I think it departs quite a bit from your initial proposal, making it
slightly more complicated on the include path side, but it has pros
like:
* making it more homogeneous on the installation side;
* allows co-installability of major releases in the future.
Opinions?
Works for me, just tell me your preference on the two points I
mentionned above.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On Thursday 14 November 2013 18:04:57 Aurélien Gâteau wrote:
On 10.11.2013 18:27, Kevin Ottens wrote:
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding folders
in header files.
I think there's an aspect missing in your proposal. There's the
convention we want for #include and where we install. That's in the
end two different things even though related.
I think, that for all the frameworks, headers should be installed in:
$PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and the
convenience camel case ones. If we go for that, we get something
consistent install wise and easy to deal with. Then the distinction
you make below is just about the include path we want when someone
pulls a framework in.
I think the consensus is there should be two different situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then
headers should be installed in include and convenience headers
should
be installed in include/KDE.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then both
$PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are
added
in the include path, thus supporting the #include kfoo.h and
#include KFoo styles.
To support #include kfoo.h and #include KFoo you only need to have
$PREFIX/include/KF5/FrameworkName/ in the include path. Adding
$PREFIX/include/KF5/ would add support for
#include FrameworkName/kfoo.h and #include FrameworkName/KFoo.
In fact I initially mentionned $PREFIX/include/KF5/ because of your initial
proposal of having *_version.h and *_export.h one level up.
Do we want to support this as well? (I have no strong opinion on this
topic)
Honestly I don't have a strong opinion either. I'd say we probably don't want
it (they have it in Qt and we've seen the kind of issues it can create during
ports when something is splitted for instance). If it turns out to be
troublesome to not have it, we'll be able to reintroduce it later easily
anyway.
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they
should
be installed in include/{lowercaseframework} and convenience headers
should be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then only
$PREFIX/include/KF5/ is added in the include path, thus supporting
the
#include FrameworkName/foo.h and #include FrameworkName/Foo
styles.
Some special files should still go in include:
{lowercaseframework}_export.h {lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I agree.
Wouldn't it be more self-contained to have those in
$PREFIX/include/KF5/FrameworkName as well?
After all, those includes are mostly internal, so they should not be
the first files you meet if you wander in $PREFIX/include/KF5 IMO.
Right. Let's put them in the FrameworkName directory as well then.
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Fwd: RFC Rules for installation of header files
On Thu, Nov 14, 2013 at 5:04 PM, Aurélien Gâteau agat...@kde.org wrote:
On 10.11.2013 18:27, Kevin Ottens wrote:
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding folders
in header files.
I think there's an aspect missing in your proposal. There's the
convention we want for #include and where we install. That's in the
end two different things even though related.
I think, that for all the frameworks, headers should be installed in:
$PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and the
convenience camel case ones. If we go for that, we get something
consistent install wise and easy to deal with. Then the distinction
you make below is just about the include path we want when someone
pulls a framework in.
I think the consensus is there should be two different situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then
headers should be installed in include and convenience headers should
be installed in include/KDE.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then both
$PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are added
in the include path, thus supporting the #include kfoo.h and
#include KFoo styles.
To support #include kfoo.h and #include KFoo you only need to have
$PREFIX/include/KF5/FrameworkName/ in the include path. Adding
$PREFIX/include/KF5/ would add support for
#include FrameworkName/kfoo.h and #include FrameworkName/KFoo.
Do we want to support this as well? (I have no strong opinion on this
topic)
ecm_generate_headers will do it like that anyway
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they should
be installed in include/{lowercaseframework} and convenience headers
should be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then only
$PREFIX/include/KF5/ is added in the include path, thus supporting the
#include FrameworkName/foo.h and #include FrameworkName/Foo
styles.
Some special files should still go in include:
{lowercaseframework}_export.h {lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I agree.
Wouldn't it be more self-contained to have those in
$PREFIX/include/KF5/FrameworkName as well?
After all, those includes are mostly internal, so they should not be the
first files you meet if you wander in $PREFIX/include/KF5 IMO.
They should probably be in frameworkname/frameworkname_export.h. Usually we
have 2 folders for includes, the camel case for camel case includes and the
lowercase one with the actual includes.
I think it departs quite a bit from your initial proposal, making it
slightly more complicated on the include path side, but it has pros
like:
* making it more homogeneous on the installation side;
* allows co-installability of major releases in the future.
Opinions?
Works for me, just tell me your preference on the two points I
mentionned above.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On 14.11.2013 18:20, Kevin Ottens wrote:
On Thursday 14 November 2013 18:04:57 Aurélien Gâteau wrote:
On 10.11.2013 18:27, Kevin Ottens wrote:
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding
folders
in header files.
I think there's an aspect missing in your proposal. There's the
convention we want for #include and where we install. That's in
the
end two different things even though related.
I think, that for all the frameworks, headers should be installed
in:
$PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and
the
convenience camel case ones. If we go for that, we get something
consistent install wise and easy to deal with. Then the
distinction
you make below is just about the include path we want when someone
pulls a framework in.
I think the consensus is there should be two different
situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then
headers should be installed in include and convenience headers
should
be installed in include/KDE.
I think in a case like that we still want the includes installed
in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then both
$PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are
added
in the include path, thus supporting the #include kfoo.h and
#include KFoo styles.
To support #include kfoo.h and #include KFoo you only need to
have
$PREFIX/include/KF5/FrameworkName/ in the include path. Adding
$PREFIX/include/KF5/ would add support for
#include FrameworkName/kfoo.h and #include FrameworkName/KFoo.
In fact I initially mentionned $PREFIX/include/KF5/ because of your
initial
proposal of having *_version.h and *_export.h one level up.
Do we want to support this as well? (I have no strong opinion on
this
topic)
Honestly I don't have a strong opinion either. I'd say we probably
don't want
it (they have it in Qt and we've seen the kind of issues it can
create during
ports when something is splitted for instance). If it turns out to be
troublesome to not have it, we'll be able to reintroduce it later
easily
anyway.
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they
should
be installed in include/{lowercaseframework} and convenience
headers
should be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed
in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then only
$PREFIX/include/KF5/ is added in the include path, thus supporting
the
#include FrameworkName/foo.h and #include FrameworkName/Foo
styles.
Some special files should still go in include:
{lowercaseframework}_export.h {lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I
agree.
Wouldn't it be more self-contained to have those in
$PREFIX/include/KF5/FrameworkName as well?
After all, those includes are mostly internal, so they should not be
the first files you meet if you wander in $PREFIX/include/KF5 IMO.
Right. Let's put them in the FrameworkName directory as well then.
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
non-prefixed headers such as bar.h and Bar, as well as special headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: RFC Rules for installation of header files
On 14.11.2013 18:31, Aleix Pol wrote:
On Thu, Nov 14, 2013 at 5:04 PM, Aurélien Gâteau agat...@kde.org
[3]
wrote:
On 10.11.2013 18:27, Kevin Ottens wrote:
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding
folders
in header files.
I think there's an aspect missing in your proposal. There's the
convention we want for #include and where we install. That's in the
end two different things even though related.
I think, that for all the frameworks, headers should be installed
in: $PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and
the
convenience camel case ones. If we go for that, we get something
consistent install wise and easy to deal with. Then the distinction
you make below is just about the include path we want when someone
pulls a framework in.
I think the consensus is there should be two different situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then
headers should be installed in include and convenience headers
should be installed in include/KDE.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then both
$PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are
added in the include path, thus supporting the #include kfoo.h
and
#include KFoo styles.
To support #include kfoo.h and #include KFoo you only need to
have $PREFIX/include/KF5/FrameworkName/ in the include path. Adding
$PREFIX/include/KF5/ would add support for #include
FrameworkName/kfoo.h and #include FrameworkName/KFoo.
Do we want to support this as well? (I have no strong opinion on
this
topic)
ecm_generate_headers will do it like that anyway
Mmm, this is not about installation path, but about the include path.
Does ecm_generate_headers affects the include path?
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they
should be installed in include/{lowercaseframework} and
convenience
headers should be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then only
$PREFIX/include/KF5/ is added in the include path, thus supporting
the #include FrameworkName/foo.h and #include FrameworkName/Foo
styles.
Some special files should still go in include:
{lowercaseframework}_export.h {lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I agree.
Wouldn't it be more self-contained to have those in
$PREFIX/include/KF5/FrameworkName as well?
After all, those includes are mostly internal, so they should not be
the first files you meet if you wander in $PREFIX/include/KF5 IMO.
They should probably be in frameworkname/frameworkname_export.h.
Usually we have 2 folders for includes, the camel case for camel case
includes and the lowercase one with the actual includes.
Unless I am confused, Kevin proposal is to have only one folder:
$PREFIX/include/KF5/$Framework. This folder would contain both lower
case and camel case header files.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote:
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
I assume you meant kfoo.h here.
non-prefixed headers such as bar.h and Bar, as well as special headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Looks correct to me.
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: RFC Rules for installation of header files
On Thursday 14 November 2013 18:43:59 Aleix Pol wrote:
On 14.11.2013 18:31, Aleix Pol wrote:
On Thu, Nov 14, 2013 at 5:04 PM, Aurélien Gâteau agat...@kde.org
[3]
wrote:
On 10.11.2013 18:27, Kevin Ottens wrote:
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding
folders
in header files.
I think there's an aspect missing in your proposal. There's the
convention we want for #include and where we install. That's in the
end two different things even though related.
I think, that for all the frameworks, headers should be installed
in: $PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and
the
convenience camel case ones. If we go for that, we get something
consistent install wise and easy to deal with. Then the distinction
you make below is just about the include path we want when someone
pulls a framework in.
I think the consensus is there should be two different situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then
headers should be installed in include and convenience headers
should be installed in include/KDE.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then both
$PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are
added in the include path, thus supporting the #include kfoo.h
and
#include KFoo styles.
To support #include kfoo.h and #include KFoo you only need to
have $PREFIX/include/KF5/FrameworkName/ in the include path. Adding
$PREFIX/include/KF5/ would add support for #include
FrameworkName/kfoo.h and #include FrameworkName/KFoo.
Do we want to support this as well? (I have no strong opinion on
this
topic)
ecm_generate_headers will do it like that anyway
Mmm, this is not about installation path, but about the include path.
Does ecm_generate_headers affects the include path?
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they
should be installed in include/{lowercaseframework} and
convenience
headers should be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then only
$PREFIX/include/KF5/ is added in the include path, thus supporting
the #include FrameworkName/foo.h and #include FrameworkName/Foo
styles.
Some special files should still go in include:
{lowercaseframework}_export.h {lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I agree.
Wouldn't it be more self-contained to have those in
$PREFIX/include/KF5/FrameworkName as well?
After all, those includes are mostly internal, so they should not be
the first files you meet if you wander in $PREFIX/include/KF5 IMO.
They should probably be in frameworkname/frameworkname_export.h.
Usually we have 2 folders for includes, the camel case for camel case
includes and the lowercase one with the actual includes.
Unless I am confused, Kevin proposal is to have only one folder:
$PREFIX/include/KF5/$Framework. This folder would contain both lower
case and camel case header files.
Yes, that's what I propose.
Aurélien
This thread is confusing, I don't know who I'm replying to... From: said
Aleix, signature Aurélien... Did you guys merge or something? :-)
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: RFC Rules for installation of header files
This thread is confusing, I don't know who I'm replying to... From: said Aleix, signature Aurélien... Did you guys merge or something? :-) Nah, we did not. My webmail is screwed up and by default sets the From field to the sender of the mail I am replying to. Sorry Aleix for impersonating you. Just asked the support of my email host to look into that. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On 14.11.2013 18:55, Kevin Ottens wrote: On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote: Looks like we have an agreement then. Let me recap: # Installation dir All header files are installed in $PREFIX/include/KF5/$Framework. This includes 'k' prefixed headers like kfoo and KFoo, I assume you meant kfoo.h here. Oups, yes, indeed. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113867: Add knewstuff public dependencies to it's config.cmake file.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113867/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- KNewStuff's Config.cmake is missing it's public dependencies. This adds them. Diffs - tier3/knewstuff/KNewStuffConfig.cmake.in 54bee483444919ee0a337d117ff5f48139d04359 Diff: http://git.reviewboard.kde.org/r/113867/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113867: Add knewstuff public dependencies to it's config.cmake file.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113867/#review43690 --- Ship it! Ship It! - Aleix Pol Gonzalez On Nov. 14, 2013, 6:03 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113867/ --- (Updated Nov. 14, 2013, 6:03 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KNewStuff's Config.cmake is missing it's public dependencies. This adds them. Diffs - tier3/knewstuff/KNewStuffConfig.cmake.in 54bee483444919ee0a337d117ff5f48139d04359 Diff: http://git.reviewboard.kde.org/r/113867/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113867: Add knewstuff public dependencies to it's config.cmake file.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113867/ --- (Updated Nov. 14, 2013, 6:40 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- KNewStuff's Config.cmake is missing it's public dependencies. This adds them. Diffs - tier3/knewstuff/KNewStuffConfig.cmake.in 54bee483444919ee0a337d117ff5f48139d04359 Diff: http://git.reviewboard.kde.org/r/113867/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113867: Add knewstuff public dependencies to it's config.cmake file.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113867/#review43691 --- This review has been submitted with commit 91f29c4eeb690737499206753bb2c0ee8aba1bae by Jeremy Whiting to branch frameworks. - Commit Hook On Nov. 14, 2013, 6:03 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113867/ --- (Updated Nov. 14, 2013, 6:03 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- KNewStuff's Config.cmake is missing it's public dependencies. This adds them. Diffs - tier3/knewstuff/KNewStuffConfig.cmake.in 54bee483444919ee0a337d117ff5f48139d04359 Diff: http://git.reviewboard.kde.org/r/113867/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kdelibs_frameworks_qt5 #1677
See http://build.kde.org/job/kdelibs_frameworks_qt5/1677/changes
Changes:
[aleixpol] Rename knewstuff3 to KF5::KNewStuff
--
[...truncated 6699 lines...]
[ 80%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/misc/AtomicString.cpp.o
[ 80%] Building CXX object tier4/khtml/src/CMakeFiles/KHtml.dir/misc/woff.cpp.o
[ 80%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/misc/guess_ja.cpp.o
[ 80%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/misc/kencodingdetector.cpp.o
[ 80%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/editing/jsediting.cpp.o
[ 80%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/editing/editing.cpp.o
[ 80%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/editing/editor.cpp.o
[ 80%]
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/misc/AtomicString.cpp:
In static member function ‘static DOM::DOMStringImpl*
khtml::AtomicString::add(const QChar*, int)’:
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/misc/AtomicString.cpp:163:35:
warning: narrowing conversion of ‘length’ from ‘int’ to ‘unsigned int’ inside
{ } [-Wnarrowing]
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/misc/AtomicString.cpp:
In static member function ‘static DOM::DOMStringImpl*
khtml::AtomicString::add(const QChar*)’:
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/misc/AtomicString.cpp:183:33:
warning: narrowing conversion of ‘length’ from ‘int’ to ‘unsigned int’ inside
{ } [-Wnarrowing]
Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/editing/htmlediting_impl.cpp.o
[ 80%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_binding.cpp.o
[ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_dom.cpp.o
[ 81%] In file included from
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/css/parser.cpp:133:0:
cssproperties.gperf:167:62: warning: ‘__gnu_inline__’ attribute ignored
[-Wattributes]
In file included from
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/css/parser.cpp:134:0:
cssvalues.gperf:152:63: warning: ‘__gnu_inline__’ attribute ignored
[-Wattributes]
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/html/htmltokenizer.cpp:2080:6:
warning: unused parameter ‘finishedObj’ [-Wunused-parameter]
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/editing/htmlediting_impl.cpp:153:17:
warning: ‘DOM::Position khtml::leadingWhitespacePosition(const
DOM::Position)’ defined but not used [-Wunused-function]
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/editing/htmlediting_impl.cpp:168:17:
warning: ‘DOM::Position khtml::trailingWhitespacePosition(const
DOM::Position)’ defined but not used [-Wunused-function]
[ 81%] [ 81%] [ 81%] [ 81%] [ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_html.cpp.o
[ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_navigator.cpp.o
Building CXX object tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_window.cpp.o
Building CXX object tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_css.cpp.o
Building CXX object tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_proxy.cpp.o
Building CXX object tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_range.cpp.o
Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_traversal.cpp.o
[ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_events.cpp.o
[ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_views.cpp.o
[ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/kjs_mozilla.cpp.o
[ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/JSTimeRanges.cpp.o
In file included from
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/ecma/kjs_traversal.cpp:22:0:
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/build/tier4/khtml/src/kjs_traversal.lut.h:54:1:
warning: narrowing conversion of ‘(DOM::NodeFilter::ShowCode)4294967295u’ from
‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
[ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/JSMediaError.cpp.o
[ 81%] Building CXX object
tier4/khtml/src/CMakeFiles/KHtml.dir/ecma/JSHTMLElement.cpp.o
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/ecma/kjs_window.cpp:
In function ‘void KJS::printMessage(KJS::Console::MessageType, const
KJS::UString)’:
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/ecma/kjs_window.cpp:233:17:
warning: variable ‘type’ set but not used [-Wunused-but-set-variable]
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/ecma/kjs_window.cpp:
At global scope:
http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier4/khtml/src/ecma/kjs_window.cpp:231:6:
warning: unused parameter ‘message’ [-Wunused-parameter]
[ 81%] Building CXX object
Build failed in Jenkins: kdelibs_frameworks_qt5 #1678
See http://build.kde.org/job/kdelibs_frameworks_qt5/1678/changes Changes: [aleixpol] Update KDELibs4Config.cmake with the new KNewStuff name [jpwhiting] Add public library dependencies to KNewStuffConfig.cmake [jpwhiting] Fix whitespace in knewstuff CMakeLists.txt file. -- [...truncated 6348 lines...] [ 73%] Building CXX object tier3/knewstuff/src/CMakeFiles/KNewStuff.dir/downloadmanager.cpp.o [ 73%] [ 73%] Building CXX object tier3/kbookmarks/src/CMakeFiles/KBookmarks.dir/kbookmarkdialog.cpp.o Building CXX object tier3/kparts/src/CMakeFiles/KParts.dir/statusbarextension.cpp.o [ 73%] [ 73%] Built target kxmlguiwindowtest Building CXX object tier3/kparts/src/CMakeFiles/KParts.dir/scriptableextension.cpp.o [ 73%] Linking CXX executable kactioncategorytest Building CXX object tier3/kparts/src/CMakeFiles/KParts.dir/textextension.cpp.o [ 73%] Building CXX object tier3/knewstuff/src/CMakeFiles/KNewStuff.dir/entry.cpp.o [ 73%] Built target kxmlguitest [ 73%] Building CXX object tier3/knewstuff/src/CMakeFiles/KNewStuff.dir/knewstuffbutton.cpp.o [ 73%] Building CXX object tier3/knewstuff/src/CMakeFiles/KNewStuff.dir/knewstuffaction.cpp.o [ 73%] Building CXX object tier3/kbookmarks/src/CMakeFiles/KBookmarks.dir/KBookmarks_automoc.cpp.o [ 73%] Building CXX object tier3/kparts/src/CMakeFiles/KParts.dir/htmlextension.cpp.o [ 73%] Building CXX object tier3/kparts/src/CMakeFiles/KParts.dir/fileinfoextension.cpp.o [ 73%] Linking CXX shared library libKBookmarks.so [ 73%] Building CXX object tier3/kparts/src/CMakeFiles/KParts.dir/listingextension.cpp.o Building CXX object tier3/kparts/src/CMakeFiles/KParts.dir/KParts_automoc.cpp.o Scanning dependencies of target kglobalshortcuttest [ 73%] Building CXX object tier3/xmlgui/autotests/CMakeFiles/kglobalshortcuttest.dir/kglobalshortcuttest.cpp.o [ 73%] Building CXX object tier3/xmlgui/autotests/CMakeFiles/kglobalshortcuttest.dir/kglobalshortcuttest_automoc.cpp.o Linking CXX shared library libKParts.so [ 73%] [ 73%] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/autotests/kglobalshortcuttest.cpp: In member function ‘void KGlobalShortcutTest::setupTest(QString)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/autotests/kglobalshortcuttest.cpp:77:60: warning: ‘QListQStringList KGlobalAccel::allMainComponents()’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/src/kglobalaccel.h:284) [-Wdeprecated-declarations] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/autotests/kglobalshortcuttest.cpp: In member function ‘void KGlobalShortcutTest::testListActions()’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/autotests/kglobalshortcuttest.cpp:253:60: warning: ‘QListQStringList KGlobalAccel::allMainComponents()’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/src/kglobalaccel.h:284) [-Wdeprecated-declarations] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/autotests/kglobalshortcuttest.cpp:261:73: warning: ‘QListQStringList KGlobalAccel::allActionsForComponent(const QStringList)’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/src/kglobalaccel.h:293) [-Wdeprecated-declarations] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/autotests/kglobalshortcuttest.cpp: In member function ‘void KGlobalShortcutTest::testForgetGlobalShortcut()’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/autotests/kglobalshortcuttest.cpp:399:60: warning: ‘QListQStringList KGlobalAccel::allMainComponents()’ is deprecated (declared at http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/xmlgui/src/kglobalaccel.h:284) [-Wdeprecated-declarations] Built target kactioncollectiontest Linking CXX executable kglobalshortcuttest Building CXX object tier3/knewstuff/src/CMakeFiles/KNewStuff.dir/core/author.cpp.o Scanning dependencies of target kmainwindow_unittest [ 73%] Building CXX object tier3/xmlgui/autotests/CMakeFiles/kmainwindow_unittest.dir/kmainwindow_unittest.cpp.o [ 73%] Built target krichtexteditor [ 73%] [ 73%] Built target kactioncategorytest Building CXX object tier3/knewstuff/src/CMakeFiles/KNewStuff.dir/core/cache.cpp.o [ 74%] Building CXX object tier3/xmlgui/autotests/CMakeFiles/kmainwindow_unittest.dir/kmainwindow_unittest_automoc.cpp.o Linking CXX executable kmainwindow_unittest In file included from http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/knewstuff/src/knewstuffbutton.cpp:19:0: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier3/knewstuff/src/knewstuffbutton.h:25:30: fatal error: knewstuff3/entry.h: No such file or directory compilation terminated. make[2]: *** [tier3/knewstuff/src/CMakeFiles/KNewStuff.dir/knewstuffbutton.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs [ 74%] Building CXX object
Jenkins build is back to normal : kdelibs_frameworks_qt5 #1679
See http://build.kde.org/job/kdelibs_frameworks_qt5/1679/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
