Re: Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers
On July 14, 2014, 10:57 p.m., Aleix Pol Gonzalez wrote: Is this because of the usage of list(APPEND)? Maybe using set(.. PARENT_SCOPE) for appending would do the trick as well? Andreas Xavier wrote: Can you confirm that you are seeing the same problem? This is my first time trying to compile KF5 and the problem is most likely to be with my setup. If I know that everyone is experiencing the problem, then I will try to fix it in ecm using set( .. PARENT_SCOPE). Cristian Oneț wrote: I remember running into something similar while building using kdesrc-build. I just suspected that it's something related to my setup since it went away once I manually ran 'make install' from the build directory created by kdesrc-build. While building on Windows using emerge I didn't see this though. Alex Merry wrote: I can't reproduce this (and, additionally, the [CI system](http://build.kde.org) does a completely clean build and install every time). Can you post the output of `cmake --version`, please? Andreas Xavier wrote: Entirely my mistake. All of frameworks compiled with no changes. Thank you for taking the time to look at this. I am now running with : cmake version 3.0.20140712-g2eadd1 One nameless Konsole tab over I was running with : cmake version 2.8.12.2 It might be worth noting that with the changes in this patch cmake 2.8.12.2 was able to compile frameworks all the way to KHTML with no complaints. Clearly, I am a cmake novice, but if this patch doesn't break the build with 3.0 and it makes it possible to build it with 2.8.12.2 it might make the overall build more robust. Once again thanks for your time. Michael Pyne wrote: I'll look into whether kdesrc-build is failing on the first-ever-build use case, there's a recently-opened bug about it (bug 337446) so it's very possible. Cristian Oneț wrote: Now this is starting to make sense to me, altough kdesrc-build using extragear/utils/kdesrc-build/kf5-qt5-build-include builds cmake-git maybe it was using up cmake from my system which is 2.8.12.2 and was causing this problem. Using cmake 2.8.12.2 should be fine. I'll have to do a build with that version and check it still works. It is possible that using a mix of different CMake versions could cause issues, though. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/#review62358 --- On July 15, 2014, 9:36 p.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/ --- (Updated July 15, 2014, 9:36 p.m.) Review request for KDE Frameworks, Alex Merry and Michael Pyne. Repository: kcoreaddons Description --- Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows. ecm_generate_headers(var1 ... REQUIRED_HEADERS var2 ) It doesn't show up in existing builds because cmake doesn't delete old header files. Steps to Replicate the Problem: 1. Delete the existing header files for KCoreAddons and the existing build files. rm -r $KF5/KcoreAddons rm -r your kcoreaddons/build directory 2. Re-build kcoreaddons from a new build dir cmake -DCMAKE_INSTALL_PREFIX=$KF5 .. 3. Check in $KF5/KcoreAddons and there should only be these headers: KAboutData kaboutdata.h kcoreaddons_export.h Solution: This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase. Extended Solution: If this patch is approved, then I will 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion. 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. Diffs - src/lib/CMakeLists.txt 26eb5a1 Diff: https://git.reviewboard.kde.org/r/119275/diff/ Testing --- Compiled kcoreaddons, then checked that all headers generated and exported. Ran unittests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers
On July 14, 2014, 10:57 p.m., Aleix Pol Gonzalez wrote: Is this because of the usage of list(APPEND)? Maybe using set(.. PARENT_SCOPE) for appending would do the trick as well? Andreas Xavier wrote: Can you confirm that you are seeing the same problem? This is my first time trying to compile KF5 and the problem is most likely to be with my setup. If I know that everyone is experiencing the problem, then I will try to fix it in ecm using set( .. PARENT_SCOPE). I remember running into something similar while building using kdesrc-build. I just suspected that it's something related to my setup since it went away once I manually ran 'make install' from the build directory created by kdesrc-build. While building on Windows using emerge I didn't see this though. - Cristian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/#review62358 --- On July 14, 2014, 6 p.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/ --- (Updated July 14, 2014, 6 p.m.) Review request for KDE Frameworks, Alex Merry and Michael Pyne. Repository: kcoreaddons Description --- Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows. ecm_generate_headers(var1 ... REQUIRED_HEADERS var2 ) It doesn't show up in existing builds because cmake doesn't delete old header files. Steps to Replicate the Problem: 1. Delete the existing header files for KCoreAddons and the existing build files. rm -r $KF5/KcoreAddons rm -r your kcoreaddons/build directory 2. Re-build kcoreaddons from a new build dir cmake -DCMAKE_INSTALL_PREFIX=$KF5 .. 3. Check in $KF5/KcoreAddons and there should only be these headers: KAboutData kaboutdata.h kcoreaddons_export.h Solution: This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase. Extended Solution: If this patch is approved, then I will 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion. 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. Diffs - src/lib/CMakeLists.txt 26eb5a1 Diff: https://git.reviewboard.kde.org/r/119275/diff/ Testing --- Compiled kcoreaddons, then checked that all headers generated and exported. Ran unittests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers
On July 14, 2014, 10:57 p.m., Aleix Pol Gonzalez wrote: Is this because of the usage of list(APPEND)? Maybe using set(.. PARENT_SCOPE) for appending would do the trick as well? Andreas Xavier wrote: Can you confirm that you are seeing the same problem? This is my first time trying to compile KF5 and the problem is most likely to be with my setup. If I know that everyone is experiencing the problem, then I will try to fix it in ecm using set( .. PARENT_SCOPE). Cristian Oneț wrote: I remember running into something similar while building using kdesrc-build. I just suspected that it's something related to my setup since it went away once I manually ran 'make install' from the build directory created by kdesrc-build. While building on Windows using emerge I didn't see this though. I can't reproduce this (and, additionally, the [CI system](http://build.kde.org) does a completely clean build and install every time). Can you post the output of `cmake --version`, please? - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/#review62358 --- On July 14, 2014, 6 p.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/ --- (Updated July 14, 2014, 6 p.m.) Review request for KDE Frameworks, Alex Merry and Michael Pyne. Repository: kcoreaddons Description --- Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows. ecm_generate_headers(var1 ... REQUIRED_HEADERS var2 ) It doesn't show up in existing builds because cmake doesn't delete old header files. Steps to Replicate the Problem: 1. Delete the existing header files for KCoreAddons and the existing build files. rm -r $KF5/KcoreAddons rm -r your kcoreaddons/build directory 2. Re-build kcoreaddons from a new build dir cmake -DCMAKE_INSTALL_PREFIX=$KF5 .. 3. Check in $KF5/KcoreAddons and there should only be these headers: KAboutData kaboutdata.h kcoreaddons_export.h Solution: This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase. Extended Solution: If this patch is approved, then I will 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion. 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. Diffs - src/lib/CMakeLists.txt 26eb5a1 Diff: https://git.reviewboard.kde.org/r/119275/diff/ Testing --- Compiled kcoreaddons, then checked that all headers generated and exported. Ran unittests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers
On July 14, 2014, 10:57 p.m., Aleix Pol Gonzalez wrote: Is this because of the usage of list(APPEND)? Maybe using set(.. PARENT_SCOPE) for appending would do the trick as well? Andreas Xavier wrote: Can you confirm that you are seeing the same problem? This is my first time trying to compile KF5 and the problem is most likely to be with my setup. If I know that everyone is experiencing the problem, then I will try to fix it in ecm using set( .. PARENT_SCOPE). Cristian Oneț wrote: I remember running into something similar while building using kdesrc-build. I just suspected that it's something related to my setup since it went away once I manually ran 'make install' from the build directory created by kdesrc-build. While building on Windows using emerge I didn't see this though. Alex Merry wrote: I can't reproduce this (and, additionally, the [CI system](http://build.kde.org) does a completely clean build and install every time). Can you post the output of `cmake --version`, please? Entirely my mistake. All of frameworks compiled with no changes. Thank you for taking the time to look at this. I am now running with : cmake version 3.0.20140712-g2eadd1 One nameless Konsole tab over I was running with : cmake version 2.8.12.2 It might be worth noting that with the changes in this patch cmake 2.8.12.2 was able to compile frameworks all the way to KHTML with no complaints. Clearly, I am a cmake novice, but if this patch doesn't break the build with 3.0 and it makes it possible to build it with 2.8.12.2 it might make the overall build more robust. Once again thanks for your time. - Andreas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/#review62358 --- On July 14, 2014, 6 p.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/ --- (Updated July 14, 2014, 6 p.m.) Review request for KDE Frameworks, Alex Merry and Michael Pyne. Repository: kcoreaddons Description --- Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows. ecm_generate_headers(var1 ... REQUIRED_HEADERS var2 ) It doesn't show up in existing builds because cmake doesn't delete old header files. Steps to Replicate the Problem: 1. Delete the existing header files for KCoreAddons and the existing build files. rm -r $KF5/KcoreAddons rm -r your kcoreaddons/build directory 2. Re-build kcoreaddons from a new build dir cmake -DCMAKE_INSTALL_PREFIX=$KF5 .. 3. Check in $KF5/KcoreAddons and there should only be these headers: KAboutData kaboutdata.h kcoreaddons_export.h Solution: This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase. Extended Solution: If this patch is approved, then I will 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion. 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. Diffs - src/lib/CMakeLists.txt 26eb5a1 Diff: https://git.reviewboard.kde.org/r/119275/diff/ Testing --- Compiled kcoreaddons, then checked that all headers generated and exported. Ran unittests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/ --- (Updated July 15, 2014, 9:36 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks, Alex Merry and Michael Pyne. Repository: kcoreaddons Description --- Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows. ecm_generate_headers(var1 ... REQUIRED_HEADERS var2 ) It doesn't show up in existing builds because cmake doesn't delete old header files. Steps to Replicate the Problem: 1. Delete the existing header files for KCoreAddons and the existing build files. rm -r $KF5/KcoreAddons rm -r your kcoreaddons/build directory 2. Re-build kcoreaddons from a new build dir cmake -DCMAKE_INSTALL_PREFIX=$KF5 .. 3. Check in $KF5/KcoreAddons and there should only be these headers: KAboutData kaboutdata.h kcoreaddons_export.h Solution: This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase. Extended Solution: If this patch is approved, then I will 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion. 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. Diffs - src/lib/CMakeLists.txt 26eb5a1 Diff: https://git.reviewboard.kde.org/r/119275/diff/ Testing --- Compiled kcoreaddons, then checked that all headers generated and exported. Ran unittests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers
On July 14, 2014, 10:57 p.m., Aleix Pol Gonzalez wrote: Is this because of the usage of list(APPEND)? Maybe using set(.. PARENT_SCOPE) for appending would do the trick as well? Andreas Xavier wrote: Can you confirm that you are seeing the same problem? This is my first time trying to compile KF5 and the problem is most likely to be with my setup. If I know that everyone is experiencing the problem, then I will try to fix it in ecm using set( .. PARENT_SCOPE). Cristian Oneț wrote: I remember running into something similar while building using kdesrc-build. I just suspected that it's something related to my setup since it went away once I manually ran 'make install' from the build directory created by kdesrc-build. While building on Windows using emerge I didn't see this though. Alex Merry wrote: I can't reproduce this (and, additionally, the [CI system](http://build.kde.org) does a completely clean build and install every time). Can you post the output of `cmake --version`, please? Andreas Xavier wrote: Entirely my mistake. All of frameworks compiled with no changes. Thank you for taking the time to look at this. I am now running with : cmake version 3.0.20140712-g2eadd1 One nameless Konsole tab over I was running with : cmake version 2.8.12.2 It might be worth noting that with the changes in this patch cmake 2.8.12.2 was able to compile frameworks all the way to KHTML with no complaints. Clearly, I am a cmake novice, but if this patch doesn't break the build with 3.0 and it makes it possible to build it with 2.8.12.2 it might make the overall build more robust. Once again thanks for your time. I'll look into whether kdesrc-build is failing on the first-ever-build use case, there's a recently-opened bug about it (bug 337446) so it's very possible. - Michael --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/#review62358 --- On July 15, 2014, 9:36 p.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/ --- (Updated July 15, 2014, 9:36 p.m.) Review request for KDE Frameworks, Alex Merry and Michael Pyne. Repository: kcoreaddons Description --- Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows. ecm_generate_headers(var1 ... REQUIRED_HEADERS var2 ) It doesn't show up in existing builds because cmake doesn't delete old header files. Steps to Replicate the Problem: 1. Delete the existing header files for KCoreAddons and the existing build files. rm -r $KF5/KcoreAddons rm -r your kcoreaddons/build directory 2. Re-build kcoreaddons from a new build dir cmake -DCMAKE_INSTALL_PREFIX=$KF5 .. 3. Check in $KF5/KcoreAddons and there should only be these headers: KAboutData kaboutdata.h kcoreaddons_export.h Solution: This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase. Extended Solution: If this patch is approved, then I will 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion. 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. Diffs - src/lib/CMakeLists.txt 26eb5a1 Diff: https://git.reviewboard.kde.org/r/119275/diff/ Testing --- Compiled kcoreaddons, then checked that all headers generated and exported. Ran unittests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers
On Iulie 14, 2014, 10:57 p.m., Aleix Pol Gonzalez wrote: Is this because of the usage of list(APPEND)? Maybe using set(.. PARENT_SCOPE) for appending would do the trick as well? Andreas Xavier wrote: Can you confirm that you are seeing the same problem? This is my first time trying to compile KF5 and the problem is most likely to be with my setup. If I know that everyone is experiencing the problem, then I will try to fix it in ecm using set( .. PARENT_SCOPE). Cristian Oneț wrote: I remember running into something similar while building using kdesrc-build. I just suspected that it's something related to my setup since it went away once I manually ran 'make install' from the build directory created by kdesrc-build. While building on Windows using emerge I didn't see this though. Alex Merry wrote: I can't reproduce this (and, additionally, the [CI system](http://build.kde.org) does a completely clean build and install every time). Can you post the output of `cmake --version`, please? Andreas Xavier wrote: Entirely my mistake. All of frameworks compiled with no changes. Thank you for taking the time to look at this. I am now running with : cmake version 3.0.20140712-g2eadd1 One nameless Konsole tab over I was running with : cmake version 2.8.12.2 It might be worth noting that with the changes in this patch cmake 2.8.12.2 was able to compile frameworks all the way to KHTML with no complaints. Clearly, I am a cmake novice, but if this patch doesn't break the build with 3.0 and it makes it possible to build it with 2.8.12.2 it might make the overall build more robust. Once again thanks for your time. Michael Pyne wrote: I'll look into whether kdesrc-build is failing on the first-ever-build use case, there's a recently-opened bug about it (bug 337446) so it's very possible. Now this is starting to make sense to me, altough kdesrc-build using extragear/utils/kdesrc-build/kf5-qt5-build-include builds cmake-git maybe it was using up cmake from my system which is 2.8.12.2 and was causing this problem. - Cristian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/#review62358 --- On Iulie 15, 2014, 9:36 p.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/ --- (Updated Iulie 15, 2014, 9:36 p.m.) Review request for KDE Frameworks, Alex Merry and Michael Pyne. Repository: kcoreaddons Description --- Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows. ecm_generate_headers(var1 ... REQUIRED_HEADERS var2 ) It doesn't show up in existing builds because cmake doesn't delete old header files. Steps to Replicate the Problem: 1. Delete the existing header files for KCoreAddons and the existing build files. rm -r $KF5/KcoreAddons rm -r your kcoreaddons/build directory 2. Re-build kcoreaddons from a new build dir cmake -DCMAKE_INSTALL_PREFIX=$KF5 .. 3. Check in $KF5/KcoreAddons and there should only be these headers: KAboutData kaboutdata.h kcoreaddons_export.h Solution: This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase. Extended Solution: If this patch is approved, then I will 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion. 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. Diffs - src/lib/CMakeLists.txt 26eb5a1 Diff: https://git.reviewboard.kde.org/r/119275/diff/ Testing --- Compiled kcoreaddons, then checked that all headers generated and exported. Ran unittests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119275: Fix: Same variable in camelCase and REQUIRED_HEADERS doesn't export all headers
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/#review62358 --- Is this because of the usage of list(APPEND)? Maybe using set(.. PARENT_SCOPE) for appending would do the trick as well? - Aleix Pol Gonzalez On July 14, 2014, 6 p.m., Andreas Xavier wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119275/ --- (Updated July 14, 2014, 6 p.m.) Review request for KDE Frameworks, Alex Merry and Michael Pyne. Repository: kcoreaddons Description --- Using the same variable name for var1 and var2 in the new ecm_generate_headers() syntax, when it is called more than once only exports the headers from the first invokation of ecm_generate_headers(), where var1 and var2 are defined as follows. ecm_generate_headers(var1 ... REQUIRED_HEADERS var2 ) It doesn't show up in existing builds because cmake doesn't delete old header files. Steps to Replicate the Problem: 1. Delete the existing header files for KCoreAddons and the existing build files. rm -r $KF5/KcoreAddons rm -r your kcoreaddons/build directory 2. Re-build kcoreaddons from a new build dir cmake -DCMAKE_INSTALL_PREFIX=$KF5 .. 3. Check in $KF5/KcoreAddons and there should only be these headers: KAboutData kaboutdata.h kcoreaddons_export.h Solution: This patch solves the problem by changing the name of var2 to KCoreAddons_HEADERS_lowercase and exporting both KCoreAddons_HEADERS and KCoreAddons_HEADERS_lowercase. Extended Solution: If this patch is approved, then I will 1. Submit patches to the other frameworks using ecm_generate_headers() in this fashion. 2. submit a patch to extra-cmake-modules to warn when var1 and var2 have the same name. Diffs - src/lib/CMakeLists.txt 26eb5a1 Diff: https://git.reviewboard.kde.org/r/119275/diff/ Testing --- Compiled kcoreaddons, then checked that all headers generated and exported. Ran unittests. Thanks, Andreas Xavier ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
