Proposal: move KWalletManager inside KWallet framework
Hello, Since the release 15.04 I see more and more users puzzled about their KDE Wallet set-up. For example, see this [1]. They have existing KDE4 wallets which get migrated by the KF5::KWallet::kwalletd5 migration agent, but have no means to look into/configure their migrated wallet, as KWalletManager5 was not released. KWalletManager is now currently located in kdeutils and one needs to build the *frameworks* branch to get KWalletManager5 that manages kwalletd5. Packagers (e.g. Luca) tell me that's no possible to release KWalletManager5 from there. So, I'd like to resubmit my old proposal: would that be possible to include KWalletManager in KF5::KWallet, in the runtime part, next to kwalletd. Or, if that's not possible, how should we handle this KWalletManager problem? [1] http://lists.opensuse.org/opensuse-factory/2015-05/msg00781.html (thanks Luca for letting me know this) -- Valentin Rusu IRC: valir ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
> On May 25, 2015, 8:09 p.m., Eike Hein wrote: > > Preserving the owner of an existing file is a good idea, but won't help if > > there isn't one yet ...? > > David Edmundson wrote: > I put in the other two fixes too, the next app would wipe that file and > rebuild the DB. > > Eike Hein wrote: > I guess I'm not entirely sure how root replacing the file with root > ownership and root making the file with root ownership aren't the same > problem. > > Maybe it should check for SUDO_UID and always use that uid for the file > ownership if set? > Maybe it should check for SUDO_UID and always use that uid for the file > ownership if set? wouldn't help if someone uses su instead of sudo, but for sudo users it sounds like a good idea - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80819 --- On May 21, 2015, 1:36 p.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123857/ > --- > > (Updated May 21, 2015, 1:36 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kservice > > > Description > --- > > 3 commits fixing; a crash, what caused the crash, and why we weren't auto > recovering from it. > > QFile::open() will return a Read/Write error on failed access, > PermissionsError is only in the result of a setPermissions call. > > CCBUG: 342438 > > If running as root, keep file ownership the same as the original file we're > replacing. > > $HOME is often preserved as root, making us write cache files in the > user's home directory. > > CCBUG: 342438 > > Guard against being unable to open stream > > This can happen if we are unable to open the database when a > notifyDatabaseChanged signal is emitted. > Other places guard also against this eventuality. > > BUG: 342438 > > > Diffs > - > > src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 > src/services/kservicegroupfactory.cpp > 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 > > Diff: https://git.reviewboard.kde.org/r/123857/diff/ > > > Testing > --- > > > Thanks, > > David Edmundson > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123867: Fix build on OSX clang and replace another abs with std::abs
> On May 25, 2015, 11:09 p.m., Allen Winter wrote: > > This is incorrect. std::abs comes from cstdlib, not cmath > > please fix accordingly. I have it compiling here fine on my macbook with > > #include instead of #include Fixed with http://commits.kde.org/ki18n/f0a4b6f1564efe397d804ac4ad1740c811748c6b - Bhushan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123867/#review80817 --- On May 21, 2015, 1:49 p.m., Bhushan Shah wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123867/ > --- > > (Updated May 21, 2015, 1:49 p.m.) > > > Review request for KDE Frameworks, Marko Käning, Milian Wolff, and Scarlett > Clark. > > > Repository: ki18n > > > Description > --- > > https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/1/console > > Follow up to, > > commit 8d392e523e4556f9e434f3e02890fcacfcb492e4 > Author: Milian Wolff > Date: Mon May 18 10:52:29 2015 +0200 > > Fix compiler warning about potential truncation. > > klocalizedstring.cpp:1126:46: warning: absolute value function 'abs' > given an argument of type 'long' but has parameter of type 'int' > which may cause truncation of value > > kls.d->number = static_cast(abs(a)); > ^ > klocalizedstring.cpp:1126:46: note: use function 'std::abs' instead > > > Diffs > - > > src/klocalizedstring.cpp 910f44d > > Diff: https://git.reviewboard.kde.org/r/123867/diff/ > > > Testing > --- > > > 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 123857: Fix crash after a user has launched kbuildsycoca as root.
> On May 25, 2015, 6:09 p.m., Eike Hein wrote: > > Preserving the owner of an existing file is a good idea, but won't help if > > there isn't one yet ...? > > David Edmundson wrote: > I put in the other two fixes too, the next app would wipe that file and > rebuild the DB. I guess I'm not entirely sure how root replacing the file with root ownership and root making the file with root ownership aren't the same problem. Maybe it should check for SUDO_UID and always use that uid for the file ownership if set? - Eike --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80819 --- On May 21, 2015, 11:36 a.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123857/ > --- > > (Updated May 21, 2015, 11:36 a.m.) > > > Review request for KDE Frameworks. > > > Repository: kservice > > > Description > --- > > 3 commits fixing; a crash, what caused the crash, and why we weren't auto > recovering from it. > > QFile::open() will return a Read/Write error on failed access, > PermissionsError is only in the result of a setPermissions call. > > CCBUG: 342438 > > If running as root, keep file ownership the same as the original file we're > replacing. > > $HOME is often preserved as root, making us write cache files in the > user's home directory. > > CCBUG: 342438 > > Guard against being unable to open stream > > This can happen if we are unable to open the database when a > notifyDatabaseChanged signal is emitted. > Other places guard also against this eventuality. > > BUG: 342438 > > > Diffs > - > > src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 > src/services/kservicegroupfactory.cpp > 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 > > Diff: https://git.reviewboard.kde.org/r/123857/diff/ > > > Testing > --- > > > Thanks, > > David Edmundson > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
> On May 25, 2015, 6:09 p.m., Eike Hein wrote: > > Preserving the owner of an existing file is a good idea, but won't help if > > there isn't one yet ...? I put in the other two fixes too, the next app would wipe that file and rebuild the DB. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80819 --- On May 21, 2015, 11:36 a.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123857/ > --- > > (Updated May 21, 2015, 11:36 a.m.) > > > Review request for KDE Frameworks. > > > Repository: kservice > > > Description > --- > > 3 commits fixing; a crash, what caused the crash, and why we weren't auto > recovering from it. > > QFile::open() will return a Read/Write error on failed access, > PermissionsError is only in the result of a setPermissions call. > > CCBUG: 342438 > > If running as root, keep file ownership the same as the original file we're > replacing. > > $HOME is often preserved as root, making us write cache files in the > user's home directory. > > CCBUG: 342438 > > Guard against being unable to open stream > > This can happen if we are unable to open the database when a > notifyDatabaseChanged signal is emitted. > Other places guard also against this eventuality. > > BUG: 342438 > > > Diffs > - > > src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 > src/services/kservicegroupfactory.cpp > 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 > > Diff: https://git.reviewboard.kde.org/r/123857/diff/ > > > Testing > --- > > > Thanks, > > David Edmundson > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123857: Fix crash after a user has launched kbuildsycoca as root.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123857/#review80819 --- Preserving the owner of an existing file is a good idea, but won't help if there isn't one yet ...? - Eike Hein On May 21, 2015, 11:36 a.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123857/ > --- > > (Updated May 21, 2015, 11:36 a.m.) > > > Review request for KDE Frameworks. > > > Repository: kservice > > > Description > --- > > 3 commits fixing; a crash, what caused the crash, and why we weren't auto > recovering from it. > > QFile::open() will return a Read/Write error on failed access, > PermissionsError is only in the result of a setPermissions call. > > CCBUG: 342438 > > If running as root, keep file ownership the same as the original file we're > replacing. > > $HOME is often preserved as root, making us write cache files in the > user's home directory. > > CCBUG: 342438 > > Guard against being unable to open stream > > This can happen if we are unable to open the database when a > notifyDatabaseChanged signal is emitted. > Other places guard also against this eventuality. > > BUG: 342438 > > > Diffs > - > > src/kbuildsycoca/kbuildsycoca.cpp d14f1f950cdb0d8c9fefbce2a4740f211d3d97a1 > src/services/kservicegroupfactory.cpp > 8cfc6c6670d3b87e8ed6bdfe4aeac947846afc18 > > Diff: https://git.reviewboard.kde.org/r/123857/diff/ > > > Testing > --- > > > Thanks, > > David Edmundson > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
2015-05-25 16:48 GMT+02:00 Boudewijn Rempt :
> Hi Elvis,
>
> If you've got kdemacors.h in /usr/include (for instance because you've
> also got a kde4 dev env) then you won't encounter the error. The issue is
> that the expanded list of includes is enclosed in "", which breaks the
> build.
Oh I see. Right you are.
Hm. I'm definitely no CMake expert, but perhaps there's a way of iterating
the generator expression contained in ${KDE4_INCLUDES}, and add them in one
by one using include_directories? Maybe that's more robust?
I'll let some expert comment on that. It feels we're getting closer at
least.
Elvis
>
>
> On Mon, 25 May 2015, Elvis Stansvik wrote:
>
> 2015-05-25 16:13 GMT+02:00 Boudewijn Rempt :
>> Weird, it worked for me:
>>
>> https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't
>> used or needed in the example at all.
>>
>>
>> I seem to be getting the same result as Alex (I think):
>> https://paste.kde.org/pke2ztbok
>>
>> I'm a little pussled by your paste, what is wrong with the compile line?
>> You do have -I/usr/include/KF5/KDELibs4Support in there, which should
>> contain kdemacros.h?
>>
>> Elvis
>>
>>
>>
>> On Mon, 25 May 2015, Alex Merry wrote:
>>
>> On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote:
>> http://www.valdyas.org/~boud/vc-cmake-3.tgz is as
>> minimal as I know how to
>> make it: you still need qt, KDELibs4Support and
>> extra-cmake-modules
>> installed. After that, running cmake and make VERBOSE=1
>> will give the
>> exact problem I've got.
>>
>>
>> I get compiler issues with that, but the problems I'm getting
>> are because
>> KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include
>> KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a
>> ; after the class
>> definition, and when I fix those I get multiple definition
>> errors for
>> Bla::bla(). The includes are ending up on the command line
>> just fine.
>>
>> This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or
>> cmake-3.2.2.
>>
>> Alex
>>
>> ___
>> calligra-devel mailing list
>> calligra-de...@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>>
>>
>>
> ___
> calligra-devel mailing list
> calligra-de...@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
2015-05-25 16:13 GMT+02:00 Boudewijn Rempt : > Weird, it worked for me: > > https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used or > needed in the example at all. I seem to be getting the same result as Alex (I think): https://paste.kde.org/pke2ztbok I'm a little pussled by your paste, what is wrong with the compile line? You do have -I/usr/include/KF5/KDELibs4Support in there, which should contain kdemacros.h? Elvis > > > On Mon, 25 May 2015, Alex Merry wrote: > > On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote: >> >>> http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how >>> to >>> make it: you still need qt, KDELibs4Support and extra-cmake-modules >>> installed. After that, running cmake and make VERBOSE=1 will give the >>> exact problem I've got. >>> >> >> I get compiler issues with that, but the problems I'm getting are because >> KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include >> KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the >> class >> definition, and when I fix those I get multiple definition errors for >> Bla::bla(). The includes are ending up on the command line just fine. >> >> This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2. >> >> Alex >> >> ___ > calligra-devel mailing list > calligra-de...@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123867: Fix build on OSX clang and replace another abs with std::abs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123867/#review80817 --- This is incorrect. std::abs comes from cstdlib, not cmath please fix accordingly. I have it compiling here fine on my macbook with #include instead of #include - Allen Winter On May 21, 2015, 8:19 a.m., Bhushan Shah wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123867/ > --- > > (Updated May 21, 2015, 8:19 a.m.) > > > Review request for KDE Frameworks, Marko Käning, Milian Wolff, and Scarlett > Clark. > > > Repository: ki18n > > > Description > --- > > https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/1/console > > Follow up to, > > commit 8d392e523e4556f9e434f3e02890fcacfcb492e4 > Author: Milian Wolff > Date: Mon May 18 10:52:29 2015 +0200 > > Fix compiler warning about potential truncation. > > klocalizedstring.cpp:1126:46: warning: absolute value function 'abs' > given an argument of type 'long' but has parameter of type 'int' > which may cause truncation of value > > kls.d->number = static_cast(abs(a)); > ^ > klocalizedstring.cpp:1126:46: note: use function 'std::abs' instead > > > Diffs > - > > src/klocalizedstring.cpp 910f44d > > Diff: https://git.reviewboard.kde.org/r/123867/diff/ > > > Testing > --- > > > 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 123902: Missing "or" when looking for .cmake and CMakeLists.txt files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123902/ --- (Updated May 25, 2015, 4:06 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Plasma, Kevin Ottens, and Burkhard Lück. Changes --- Submitted with commit 1fcdc08826659245a4c39ff0cb1b11b02faf by Jaroslaw Staniek to branch master. Repository: plasma-framework Description --- Missing "or" when looking for .cmake and CMakeLists.txt files Diffs - src/tools/port-cmake-style.sh e182e60abe32fbcf379871abbe6b491e9678cd25 Diff: https://git.reviewboard.kde.org/r/123902/diff/ Testing --- Finds well now Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
Hi Elvis, If you've got kdemacors.h in /usr/include (for instance because you've also got a kde4 dev env) then you won't encounter the error. The issue is that the expanded list of includes is enclosed in "", which breaks the build. On Mon, 25 May 2015, Elvis Stansvik wrote: 2015-05-25 16:13 GMT+02:00 Boudewijn Rempt : Weird, it worked for me: https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used or needed in the example at all. I seem to be getting the same result as Alex (I think): https://paste.kde.org/pke2ztbok I'm a little pussled by your paste, what is wrong with the compile line? You do have -I/usr/include/KF5/KDELibs4Support in there, which should contain kdemacros.h? Elvis On Mon, 25 May 2015, Alex Merry wrote: On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote: http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to make it: you still need qt, KDELibs4Support and extra-cmake-modules installed. After that, running cmake and make VERBOSE=1 will give the exact problem I've got. I get compiler issues with that, but the problems I'm getting are because KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the class definition, and when I fix those I get multiple definition errors for Bla::bla(). The includes are ending up on the command line just fine. This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2. Alex ___ calligra-devel mailing list calligra-de...@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123902: Missing "or" when looking for .cmake and CMakeLists.txt files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123902/#review80811 --- Ship it! Ship It! - Aleix Pol Gonzalez On May 25, 2015, 4:31 p.m., Jarosław Staniek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123902/ > --- > > (Updated May 25, 2015, 4:31 p.m.) > > > Review request for KDE Frameworks, Plasma, Kevin Ottens, and Burkhard Lück. > > > Repository: plasma-framework > > > Description > --- > > Missing "or" when looking for .cmake and CMakeLists.txt files > > > Diffs > - > > src/tools/port-cmake-style.sh e182e60abe32fbcf379871abbe6b491e9678cd25 > > Diff: https://git.reviewboard.kde.org/r/123902/diff/ > > > Testing > --- > > Finds well now > > > Thanks, > > Jarosław Staniek > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123902: Missing "or" when looking for .cmake and CMakeLists.txt files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123902/ --- Review request for KDE Frameworks, Plasma, Kevin Ottens, and Burkhard Lück. Repository: plasma-framework Description --- Missing "or" when looking for .cmake and CMakeLists.txt files Diffs - src/tools/port-cmake-style.sh e182e60abe32fbcf379871abbe6b491e9678cd25 Diff: https://git.reviewboard.kde.org/r/123902/diff/ Testing --- Finds well now Thanks, Jarosław Staniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Mon, 25 May 2015, Stephen Kelly wrote:
Boudewijn Rempt wrote:
Here's an SSCCE that demonstrates the problem with Vc 0.7.4:
cmake_minimum_required(VERSION 3.0)
project(VcTest)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
find_package(Qt5Core REQUIRED)
find_package(Vc REQUIRED)
# Uncomment this to make the build work
# include_directories(${Qt5Core_INCLUDE_DIRS})
vc_compile_for_all_implementations(__per_arch_factory_objs
hello.cpp
FLAGS -fPIC ONLY SSE2)
message("Following objects are generated from the per-arch lib:
${__per_arch_factory_objs}
")
add_executable(hello ${__per_arch_factory_objs})
target_link_libraries(hello Qt5::Core)
At first, I did not get a build failure because I used Vc from the master
branch. Commit b23418cd (change vc_compile_for_all_implementations macro to
use normal cmake compilation, 2013-10-05) removed the code which reads the
INCLUDE_DIRECTORIES directory property.
That fact gives you more options for a way forward, right?
Yes, indeed - I can try copy the vcmacros from vc master to calligra and
use those. We can't use vc master because we're dependent on released
versions, but at least we've got something new to try!
Boudewijn
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
Hm, to expand on that: if you're running into compile problems, well, then my problem would be solved. I've tested on kubuntu vivid, with cmake 3.0.2 and the 5.9.0 packages. On Mon, 25 May 2015, Boudewijn Rempt wrote: Weird, it worked for me: https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used or needed in the example at all. On Mon, 25 May 2015, Alex Merry wrote: On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote: http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to make it: you still need qt, KDELibs4Support and extra-cmake-modules installed. After that, running cmake and make VERBOSE=1 will give the exact problem I've got. I get compiler issues with that, but the problems I'm getting are because KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the class definition, and when I fix those I get multiple definition errors for Bla::bla(). The includes are ending up on the command line just fine. This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2. Alex ___ Kde-buildsystem mailing list kde-buildsys...@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
Weird, it worked for me: https://paste.kde.org/pmvwwhyqp -- in fact, the header file isn't used or needed in the example at all. On Mon, 25 May 2015, Alex Merry wrote: On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote: http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to make it: you still need qt, KDELibs4Support and extra-cmake-modules installed. After that, running cmake and make VERBOSE=1 will give the exact problem I've got. I get compiler issues with that, but the problems I'm getting are because KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the class definition, and when I fix those I get multiple definition errors for Bla::bla(). The includes are ending up on the command line just fine. This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Monday 25 May 2015 15:31:52 Boudewijn Rempt wrote: > http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to > make it: you still need qt, KDELibs4Support and extra-cmake-modules > installed. After that, running cmake and make VERBOSE=1 will give the > exact problem I've got. I get compiler issues with that, but the problems I'm getting are because KoOptimizedCompositeOpFactoryPerArch.cpp doesn't include KoOptimizedCompositeOpFactoryPerArch.h, which doesn't have a ; after the class definition, and when I fix those I get multiple definition errors for Bla::bla(). The includes are ending up on the command line just fine. This is true no matter if I use cmake-3.0.2, cmake-3.1.3 or cmake-3.2.2. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123852: Optimize: Do not wipe dict cache when copying speller objects.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123852/ --- (Updated May 25, 2015, 1:59 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Laurent Montel, Martin Tobias Holmedahl Sandsmark, and Kåre Särs. Changes --- Submitted with commit 1334cdcbce2f355455faf0bf9693881462c20416 by Milian Wolff to branch master. Repository: sonnet Description --- This removes a serious performance penalty from enabling on-the-fly spell checking in KTextEditor. For some reason, the copy assignment of a Speller object invalidated the internal cache which happened very often from the Kate code base. Now, the cache is kept valid and reused, and the performance is good again. I'm not sure whether this has any unintentional side-effects, but the tests work fine and spell checking in KatePart still looks good as well, and is now fast again. E.g. previously I easily ended up with heaptrack reports such as this one: 2284529 calls to allocation functions with 16.23MB peak consumption from HashMgr::add_word(char const*, int, int, unsigned short*, int, char const*, bool) in /usr/lib/libhunspell-1.3.so.0 1978045 calls with 2.30MB peak consumption from: HashMgr::load_tables(char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 HashMgr::HashMgr(char const*, char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 Hunspell::Hunspell(char const*, char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 HunspellDict at .../sonnet/src/plugins/hunspell/hunspelldict.cpp:36 in /home/milian/projects/compiled/kf5/lib64/plugins/kf5/sonnet/hunspell.so HunspellClient::createSpeller(QString const&) at .../sonnet/src/plugins/hunspell/hunspellclient.cpp:43 in /home/milian/projects/compiled/kf5/lib64/plugins/kf5/sonnet/hunspell.so Sonnet::Loader::createSpeller(QString const&, QString const&) const at .../sonnet/src/core/loader.cpp:103 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::Private::updateDict() at .../sonnet/src/core/speller.cpp:64 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::Private::recreateDict() at .../sonnet/src/core/speller.cpp:79 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::operator=(Sonnet::Speller const&) at .../sonnet/src/core/speller.cpp:111 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::BackgroundChecker::setSpeller(Sonnet::Speller const&) at .../sonnet/src/core/backgroundchecker.cpp:131 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 KateOnTheFlyChecker::performSpellCheck() at .../ktexteditor/src/spellcheck/ontheflycheck.cpp:405 in /home/milian/projects/compiled/kf5/lib64/libKF5TextEditor.so.5 Diffs - src/core/speller.cpp 3903b42ebb4f7cb98a049fcf7a291c74dd9457e0 Diff: https://git.reviewboard.kde.org/r/123852/diff/ Testing --- Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Mon, 25 May 2015, Stephen Kelly wrote: Boudewijn Rempt wrote: Yes, exactly. I've tried to find some documenation about this change, but apart from the rather unhelpful info in e.g. http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html I couldn't find anything. I don't even understand why "cmake is moving towards doing things at the target level". You might also find http://www.cmake.org/cmake/help/v3.2/manual/cmake-buildsystem.7.html helpful to your understanding. Hm, that doesn't sound too hopeful :-(. I haven't looked into what vc is yet. What is needed here is a SSCCE http://sscce.org/ and demonstrate that that doesn't work. If a SSCCE exists, I'm more likely to be able to help you. http://www.valdyas.org/~boud/vc-cmake-3.tgz is as minimal as I know how to make it: you still need qt, KDELibs4Support and extra-cmake-modules installed. After that, running cmake and make VERBOSE=1 will give the exact problem I've got. Boudewijn ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Mon, 25 May 2015, Alex Merry wrote:
include_directories("$")
Well, I've tried that before, I think... It expands to this:
/usr/bin/c++ -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -O3 -g -Wabi
-fabi-version=0 -ffp-contract=fast -mtune=core-avx-i -fPIC
-I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
-I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
"-I/usr/include/KF5/KDELibs4Support -I/usr/include/KF5/KDELibs4Support/KDE
-I/usr/include/KF5 -I/usr/include/qt5/ -I/usr/include/qt5/QtWidgets
-I/usr/include/qt5/ -I/usr/include/qt5/QtGui -I/usr/include/qt5/
-I/usr/include/qt5/QtCore -I/usr/lib64/qt5//mkspecs/linux-g++
-I/usr/include/qt5/ -I/usr/include/qt5/QtDBus -I/usr/include/qt5/
-I/usr/include/qt5/QtPrintSupport -I/usr/include/KF5/KCoreAddons
-I/usr/include/KF5 -I/usr/include/KF5/KCrash -I/usr/include/KF5
-I/usr/include/KF5/KWidgetsAddons -I/usr/include/KF5
-I/usr/include/KF5/KConfigCore -I/usr/include/KF5
-I/usr/include/KF5/KConfigWidgets -I/usr/include/KF5
-I/usr/include/KF5/KCodecs -I/usr/include/KF5
-I/usr/include/KF5/KConfigGui -I/usr/include/KF5 -I/usr/include/qt5/
-I/usr/include/qt5/QtXml -I/usr/include/KF5/KAuth -I/usr/include/KF5
-I/usr/include/KF5/KIOCore -I/usr/include/KF5 -I/usr/include/KF5/KService
-I/usr/include/KF5 -I/usr/include/KF5/KIOFileWidgets -I/usr/include/KF5
-I/usr/include/KF5/KIOWidgets -I/usr/include/KF5
-I/usr/include/KF5/KJobWidgets -I/usr/include/KF5 -I/usr/include/qt5/
-I/usr/include/qt5/QtNetwork -I/usr/include/KF5/KCompletion
-I/usr/include/KF5 -I/usr/include/KF5/KBookmarks -I/usr/include/KF5
-I/usr/include/KF5/KItemViews -I/usr/include/KF5
-I/usr/include/KF5/KXmlGui -I/usr/include/KF5 -I/usr/include/KF5/Solid
-I/usr/include/KF5 -I/usr/include/KF5/KI18n -I/usr/include/KF5
-I/usr/include/KF5/KNotifications -I/usr/include/KF5
-I/usr/include/KF5/KIconThemes -I/usr/include/KF5
-I/usr/include/KF5/KWindowSystem -I/usr/include -I/usr/include
-I/usr/include/KF5 -I/usr/include/KF5 -I/usr/include/KF5/KGuiAddons
-I/usr/include/KF5 -I/usr/include/KF5/KUnitConversion -I/usr/include/KF5
-I/usr/include/KF5/KTextWidgets -I/usr/include/KF5
-I/usr/include/KF5/SonnetUi -I/usr/include/KF5 -I/usr/include/KF5/KParts
-I/usr/include/KF5"
"-I/usr/include/KF5/KDELibs4Support;/usr/include/KF5/KDELibs4Support/KDE;/usr/include/KF5;/usr/include/qt5/;/usr/include/qt5/QtWidgets;/usr/include/qt5/;/usr/include/qt5/QtGui;/usr/include/qt5/;/usr/include/qt5/QtCore;/usr/lib64/qt5//mkspecs/linux-g++;/usr/include/qt5/;/usr/include/qt5/QtDBus;/usr/include/qt5/;/usr/include/qt5/QtPrintSupport;/usr/include/KF5/KCoreAddons;/usr/include/KF5;/usr/include/KF5/KCrash;/usr/include/KF5;/usr/include/KF5/KWidgetsAddons;/usr/include/KF5;/usr/include/KF5/KConfigCore;/usr/include/KF5;/usr/include/KF5/KConfigWidgets;/usr/include/KF5;/usr/include/KF5/KCodecs;/usr/include/KF5;/usr/include/KF5/KConfigGui;/usr/include/KF5;/usr/include/qt5/;/usr/include/qt5/QtXml;/usr/include/KF5/KAuth;/usr/include/KF5;/usr/include/KF5/KIOCore;/usr/include/KF5;/usr/include/KF5/KService;/usr/include/KF5;/usr/include/KF5/KIOFileWidgets;/usr/include/KF5;/usr/include/KF5/KIOWidgets;/usr/include/KF5;/usr/include/KF5/KJobWidgets;/usr/include/KF5;/usr/include/qt5/;/usr
/include/qt5/QtNetwork;/usr/include/KF5/KCompletion;/usr/include/KF5;/usr/include/KF5/KBookmarks;/usr/include/KF5;/usr/include/KF5/KItemViews;/usr/include/KF5;/usr/include/KF5/KXmlGui;/usr/include/KF5;/usr/include/KF5/Solid;/usr/include/KF5;/usr/include/KF5/KI18n;/usr/include/KF5;/usr/include/KF5/KNotifications;/usr/include/KF5;/usr/include/KF5/KIconThemes;/usr/include/KF5;/usr/include/KF5/KWindowSystem;/usr/include;/usr/include;/usr/include/KF5;/usr/include/KF5;/usr/include/KF5/KGuiAddons;/usr/include/KF5;/usr/include/KF5/KUnitConversion;/usr/include/KF5;/usr/include/KF5/KTextWidgets;/usr/include/KF5;/usr/include/KF5/SonnetUi;/usr/include/KF5;/usr/include/KF5/KParts;/usr/include/KF5"
-I/usr/include/qt5 -I/usr/include/qt5/QtCore
-I/usr/lib64/qt5/mkspecs/linux-g++ -I/usr/include/qt5
-I/usr/include/qt5/QtGui -I/usr/include/qt5/QtCore
-I/usr/lib64/qt5/mkspecs/linux-g++ -I/usr/include/qt5
-I/usr/include/qt5/QtXml -I/usr/include/qt5/QtCore
-I/usr/lib64/qt5/mkspecs/linux-g++
-I/home/boud/kde/src/calligra/libs/koplugin
-I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
-I/home/boud/kde/src/calligra/libs/pigment
-I/home/boud/kde/src/calligra/libs/pigment/compositeops
-I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
-I/usr/include -I/usr/include/OpenEXR -I/usr/local/include -mavx
-DVC_IMPL=AVX -c -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
_
Re: Problem using Vc with CMake 3.0 and kf5
On Monday 25 May 2015 13:50:08 Boudewijn Rempt wrote: > On Mon, 25 May 2015, Alex Merry wrote: > > Ah, yes. You may get somewhere with > > include_directories($) > > > > Basically, this should replace all those semicolons in the generated > > output > > with " -I", which should produce a correct command line. This is untested, > > though. > > Hm... No luck here. This outputs an error on running cmake: > > CMake Error in libs/pigment/CMakeLists.txt: >Found relative path while evaluating include directories of > "pigmentcms": > > "$") Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Mon, 25 May 2015, Alex Merry wrote: Ah, yes. You may get somewhere with include_directories($) Basically, this should replace all those semicolons in the generated output with " -I", which should produce a correct command line. This is untested, though. Hm... No luck here. This outputs an error on running cmake: CMake Error in libs/pigment/CMakeLists.txt: Found relative path while evaluating include directories of "pigmentcms": "$https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Monday 25 May 2015 13:03:40 Boudewijn Rempt wrote:
> On Mon, 25 May 2015, Alex Merry wrote:
> > The issue here is that Vc's macros implicitly assume that all compilation
> > flags (including include paths) are done at the directory level (with
> > include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is
> > moving towards doing things at the target level (with
> > target_include_directories(), target_compile_options() and inheritance
> > from targets passed to
> > target_link_libraries()).
>
> Yes, exactly. I've tried to find some documenation about this change, but
> apart from the rather unhelpful info in e.g.
> http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.ht
> ml I couldn't find anything. I don't even understand why "cmake is moving
> towards doing things at the target level".
Well, a combination of convenience (linking against a target does all the
things necessary, so you don't have to do three separate commands to use a
library) and correctness (you'll get a configure-time error from a misspelled
target name, but not a misspelled variable, and you don't end up adding
include directories or compile flags to targets that don't need them).
> > Now, from the interface of the vc_compile_for_all_implementations macro,
> > I'm guessing that it is run before you've even created the relevant
> > target, let alone called target_link_libraries() on it. That makes things
> > a bit tricky.
> >
> > Basically, as far as I can see, you have two options. One is to use the
> > old
> > CMake style of calling include_directories() all over the place in your
> > CMake code (eg: include_directories(${Qt5Core_INCLUDE_DIRS}) when you are
> > going to be linking against Qt5::Core). I'm not sure if we expose the
> > relevant variable properly in KF5 for that approach, though.
>
> No, it doesn't. Qt5Core_INCLUDE_DIRS is fine, gives the include
> directories, ${KDE4_INCLUDES} isn't -- it evaluates to that generator
> expression I quoted.
Ah, yes. You may get somewhere with
include_directories($)
Basically, this should replace all those semicolons in the generated output
with " -I", which should produce a correct command line. This is untested,
though.
> > The other is to create a variant of vc_compile_for_all_implementations
> > that
> > takes a target rather than a variable to receive object files - this
> > should
> > ideally use generator expressions to extract include directories etc, but
> > I'm not sure if generator expressions are powerful enough to deal with
> > the compile flags properly.
>
> Hm, that doesn't sound too hopeful :-(.
Well, it should work for the include directories just fine, which seems to be
the problem you're actually hitting. Vc does some relatively complex mangling
of other compile flags, though, which I don't think can be implemented
directly using generator expressions. But the flags it cares about are
unlikely to be wrapped up in generator expressions anyway, so it probably
won't be an issue in practice.
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Mon, 25 May 2015, Alex Merry wrote:
The issue here is that Vc's macros implicitly assume that all compilation
flags (including include paths) are done at the directory level (with
include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is moving
towards doing things at the target level (with target_include_directories(),
target_compile_options() and inheritance from targets passed to
target_link_libraries()).
Yes, exactly. I've tried to find some documenation about this change, but
apart from the rather unhelpful info in e.g.
http://www.cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html
I couldn't find anything. I don't even understand why "cmake is moving
towards doing things at the target level".
Now, from the interface of the vc_compile_for_all_implementations macro, I'm
guessing that it is run before you've even created the relevant target, let
alone called target_link_libraries() on it. That makes things a bit tricky.
Basically, as far as I can see, you have two options. One is to use the old
CMake style of calling include_directories() all over the place in your CMake
code (eg: include_directories(${Qt5Core_INCLUDE_DIRS}) when you are going to
be linking against Qt5::Core). I'm not sure if we expose the relevant variable
properly in KF5 for that approach, though.
No, it doesn't. Qt5Core_INCLUDE_DIRS is fine, gives the include
directories, ${KDE4_INCLUDES} isn't -- it evaluates to that generator
expression I quoted.
The other is to create a variant of vc_compile_for_all_implementations that
takes a target rather than a variable to receive object files - this should
ideally use generator expressions to extract include directories etc, but I'm
not sure if generator expressions are powerful enough to deal with the compile
flags properly.
Hm, that doesn't sound too hopeful :-(.
Boudewijn
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Saturday 23 May 2015 11:51:55 Boudewijn Rempt wrote:
> Sorry for the extensive cross-posting in advance, please when replying, do
> a reply-all.
>
> Just so everyone is on the same page: Vc is a template library that makes
> it easy to build vectorized code using a single source file. Krita uses Vc
> to optimize blending colors, creating masks and much more. Krita uses the
> most recent Vc release, 0.7.4:
> http://code.compeng.uni-frankfurt.de/news/27
>
> We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc handle
> include directories is a big roadblock for us:
> https://git.reviewboard.kde.org/r/123179/ .
>
> In a nutshell: Vc builds many different object files from single cpp file.
> It does this by creating a custom command for each target vectorization
> extension. To do that, it needs to access the contents of
> INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
> http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMa
> cros.cmake?rev=0.7)
>
> get_directory_property(_inc INCLUDE_DIRECTORIES)
> foreach(_i ${_inc})
>list(APPEND _flags "-I${_i}")
> endforeach()
>
> In the end the command is generated like this:
>
> add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
> COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
> -DVC_IMPL=${_impl}
> ${_outfile_flag}${_out}
> ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
> MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
> IMPLICIT_DEPENDS CXX
> ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
> COMMENT "Building CXX object ${_out}"
> WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}"
> VERBATIM
> )
> KF5 uses cmake generator expressions to derive the include
> directories from the target_link_libraries lines. This means that when we
> try to build our per-extensions object files we get this:
>
>
>
> [ 0%] Building CXX object
> KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
> cd /home/boud/kde/build/calligra/libs/pigment && /usr/bin/c++
> -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
> -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
> -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type
> -D__GNUC_UBUNTU_VERSION__=0xf040a -Wabi -fabi-version=0 -ffp-contract=fast
> -mtune=core2 -fPIC -I/home/boud/kde/src/calligra/interfaces
> -I/home/boud/kde/build/calligra -I/home/boud/kde/src/calligra
> -I/home/boud/kde/src/calligra/libs/version
> -I/home/boud/kde/build/calligra/libs/version
> -I/home/boud/kde/src/calligra/libs/koplugin
> -I/home/boud/kde/src/calligra/libs/version
> -I/home/boud/kde/build/calligra/libs/version
> -I/home/boud/kde/src/calligra/libs/pigment
> -I/home/boud/kde/src/calligra/libs/pigment/compositeops
> -I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
> -I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX
> -c -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
> /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOp
> FactoryPerArch.cpp
>
> /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOp
> FactoryPerArch.cpp:22:19: fatal error: QString: No such file or directory
> #include
> ^
> compilation terminated.
> libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for
> target 'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o'
> failed
>
> On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to be
> found.
>
> If we manually set include directories like this:
>
> if (HAVE_VC)
> message("." ${KDE4_INCLUDES})
> include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
> ${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}
> ${Boost_INCLUDE_DIR}) endif()
>
> We end up with the entire include line for the contents of KDE4_INCLUDES
> ($)
> expanded to a string with quotes around it:
>
> [ 0%] Building CXX object
> KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
> cd /home/boud/kde/build/calligra/libs/pigment && /usr/bin/c++
> -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
> -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
> -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type
> -D__GNUC_UBUNTU_VERSION__=0xf040a -Wabi -fabi-version=0 -ffp-contract=fast
> -mtune=core2 -fPIC -I/home/boud/kde/src/calligra/interfaces
> -I/home/boud/kde/build/calligra -I/home/boud/kde/src/calligra
> -I/home/boud/kde/src/calligra/libs/version
> -I/home/boud/kde/build/calligra/libs/version
> "-I/usr/include/KF5/KDELibs4Support;/usr/include/KF5/KDELibs4Support/KDE;/us
> r/include/KF5;/usr/include/x86_64-linux-gnu/qt5/;/usr/include/x86_64-linux-g
> nu/qt5/QtWidgets;/usr/include/x86_64-linux-gnu/qt5/;/usr/include/x86_64-linu
> x-gnu/qt5/QtGui;/usr/include/x86_64-linux-gn
Re: Review Request 123838: Move from QDesktopWidget to QScreen
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123838/ --- (Updated May 25, 2015, 8:23 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit ca3c3dafd4f8ae4227f23d3ba57616adbf3708af by Martin Klapetek to branch master. Repository: knotifications Description --- As summary Diffs - src/kpassivepopup.cpp a3a927b src/notifybypopup.cpp 8975121 Diff: https://git.reviewboard.kde.org/r/123838/diff/ Testing --- Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123731: Cleanup handling of notifications closing
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123731/ --- (Updated May 25, 2015, 8:23 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Changes --- Submitted with commit 35900a84a8e7de77747031c3ba26ed1ac61f389f by Martin Klapetek to branch master. Repository: knotifications Description --- While investigating the cause of crash of https://bugs.kde.org/show_bug.cgi?id=342752 I've come across some loose ends in how KNotifications is handling closing of notifications. As for the crash itself, I never managed to reproduce even with special written test cases, but what happens (or seem to) is this: * KNotification object gets deleted * The destructor calls close() on all plugins * The NotifyByPopup plugin does async dbus call to close the notification and returns * KNotification's dpointer is deleted * The DBus reply returns, calling NotifyByPopup::finished() * Now for some reason the KNotification object is still not null but its dpointer is gone, so the check "if (!notification || d->notifications.contains(notification->id()))" crashes on the notification->id() call So I've made it simply return -1 when dpointer is null, which should ideally prevent the crashes Diffs - src/knotification.cpp 01962b3 src/knotificationmanager.cpp 0d9b3b0 src/knotificationmanager_p.h f8e7df8 src/notifybypopup.cpp 2f84ab0 Diff: https://git.reviewboard.kde.org/r/123731/diff/ Testing --- Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
