Re: ECM unittest fails, why?

[Ben Cooksley]

On Tue, Mar 24, 2020 at 7:48 PM Friedrich W. H. Kossebau
 wrote:
>
> Am Montag, 23. März 2020, 20:30:59 CET schrieb Friedrich W. H. Kossebau:
> > Am Sonntag, 22. März 2020, 10:50:39 CET schrieb David Faure:
> > > The CI for ECM has been failing ever since the tests were re-enabled.
> > >
> > > https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.12/job/ex
> > > tr a-cmake-modules/job/kf5-qt5%20SUSEQt5.12/103/console shows that
> > > ECMPoQmToolsTest fails with "tr_thread_test.moc: No such file or
> > > directory".
> > >
> > > I have been trying to reproduce this locally, but no such luck.
> >
> > Reason seems to be that on CI the target tr_thread_test is handled before
> > tr_thread_test_2, while for us locally the order is the other way around.
> > And with tr_thread_test_2 the file tr_thread_test.moc is generated first, so
> > present in build dir afterwards, while with tr_thread_test the automoc
> > seems not happening, other than what the code hopes (perhaps some cmake
> > policy change since that code was written?).
> >
> > In general the test setup here seems bogus a bit, as one would expect that
> > the two different test cases (1 & 2) should not share the same url for the
> > generated moc file and have them in respective exclusive include dirs.
> >
> > I might have a closer look later tonight, if no-one else would work on this.
>
> Seems the reason is that the same source file is reused for both targets,
> and the variant without automoc, explicitly calling qt5_generate_moc() on the
> source file, with target tr_thread_test_2, also sees this call (with infile
> being the source file):
> set_source_files_properties(${infile} PROPERTIES SKIP_AUTOMOC ON)
>
> That property is not bound to any target, but global for the source file. And
> as result enabling automoc with the other target tr_thread_test, by
> set_target_properties(tr_thread_test PROPERTIES AUTOMOC ON)
> will still keep cmake not doing any automoc for the very source file.
>
> So when tr_thread_test is handled first, the moc file is not yet generated,
> and thus the include of it fails.
> Why CI does this order, but not locally for us, no clue so far.

Could this ordering be a race condition by any chance?

Two of the three nodes that perform the builds on the CI system are
3rd generation Ryzen 7 systems (Octa Cores) with NVMe storage, so
there is a possibility this is the case...

>
> No idea right now how to properly fix this (possibly need to have different
> source files then, perhaps a symlink), would look again in the evening.
> So feel invited to beat me on a proper solution :)

Could we add a dependency between the targets to force the correct
ordering be followed?

>
> Cheers
> Friedrich
>
>

Cheers,
Ben

D26752: ECMAddAppIcon: Do not warn about mac and window icons if isnt a OS specific build

[Ben Cooksley]

bcooksley requested changes to this revision.
bcooksley added a comment.


  Christophe is correct here, it is worth warning developers about these issues 
regardless of the platform, so they can get the code ready for those platforms 
and test everything in their local environment as much as possible.
  I know for certain that there are developers who rely on our CI system and 
the Binary Factory to test and validate their applications (because they 
themselves do not have access to a development environment on those platforms).
  
  If this warning were to occur only on the platform(s) which it impacts then 
it would become much harder for people to fix and debug.
  
  Of course, if you aren't targeting those platforms, you can just do the 
necessary if() to not hit this path.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D26752

To: patrickelectric, apol, tcanabrava, cgiboudeaux, bcooksley
Cc: bcooksley, patrickelectric, apol, cgiboudeaux, kde-frameworks-devel, 
kde-buildsystem, LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns

D23262: disable autouic again - it breaks builds

[Ben Cooksley]

bcooksley removed a subscriber: fusitter.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D23262

To: sitter, apol, nicolasfella, cullmann
Cc: bcooksley, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, 
bencreasy, michaelh, ngraham, bruns, fusitter

Eliminating the last CI Failures

[Ben Cooksley]

Hi all,

For a while now we've had a couple of projects which have been
persistently failing on all platforms, which it would be nice to get
fixed.

If someone would like to take a look into one of the following, it
would be appreciated, and would help to eliminate the last couple of
items from the Failing tab at https://build.kde.org/

- Kajongg: Fails with a CMake error due to the build path getting
wrapped up in part of the target name. This probably needs someone
with a bit of CMake knowledge to rework how it sets up targets.

- Signon KWallet Extension: Always tries to install outside of the
prefix specified at build time, which will always fail on the CI
system (or lead to situations where your tests fail due to components
being missing or inaccessible). The fix for this would be to respect
(but warn about) the lack of alignment between the install prefix and
the system prefix.

There are also issues with Dr Konqi, Umbrello and KStars on Windows
(related to exports and linking), while Latte Dock has issues on
FreeBSD (something to do with a QMetaObject definition)

Any fixes for the above would be much appreciated!

Thanks,
Ben

D21313: Create specific directory for Qt logging categories file

[Ben Cooksley]

bcooksley added a comment.


  The Binary Factory uses the tooling shipped as part of the KDE SDK (which 
always builds everything from scratch, and I don't know if part of that 
includes ECM, hence why the issue doesn't show up there).
  
  The CI system on the other hand uses it's own tooling exclusively on all 
platforms, however because the Android image ships with a limited number of 
libraries it is reliant on the KDE SDK to provide a number of non-KDE 
libraries, and thus has to include the SDK paths when performing builds. 
Unfortunately this means that it is possible on Android for CI builds to be 
contaminated by the SDK - the result of which we're seeing here.
  
  Ideally the SDK would separate the base system (non-KDE) libraries from the 
KDE ones to avoid this issue (and the CI system could therefore rely on it's 
own build results exclusively)

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D21313

To: mlaurent, dfaure, cgiboudeaux
Cc: apol, vkrause, bcooksley, kossebau, kde-frameworks-devel, kde-buildsystem, 
LeGast00n, bencreasy, michaelh, ngraham, bruns

D21313: Create specific directory for Qt logging categories file

[Ben Cooksley]

bcooksley added a comment.


  This change appears to be responsible for all Android builds being broken.
  See https://build.kde.org/view/Failing/
  
  Could someone take a look please?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D21313

To: mlaurent, dfaure, cgiboudeaux
Cc: bcooksley, kossebau, kde-frameworks-devel, kde-buildsystem, LeGast00n, 
bencreasy, michaelh, ngraham, bruns

D21381: use org.freedesktop.appstream-glib package to validate appstream data

[Ben Cooksley]

bcooksley added a comment.


  Aleix is correct, Flatpak commands are not possible within the CI environment 
(as Docker is heavily locked down, and the containerisation and other isolation 
measures that Flatpak tries to take are locked out as a consequence)
  Not to mention that Flatpak is Linux only as well, while Appstream data isn't 
applicable to multiple platforms.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D21381

To: mgallien, aacid, yurchor, apol
Cc: bcooksley, kde-frameworks-devel, kde-buildsystem, bencreasy, michaelh, 
ngraham, bruns

D19075: Fix FindEGL

[Ben Cooksley]

bcooksley added a comment.


  If someone could please trigger all of the Dependency Builds for FreeBSD once 
this has been landed that would be appreciated: 
https://build.kde.org/view/Failing/

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D19075

To: tcberner, #automotive, hausmann, #freebsd, apol
Cc: bcooksley, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18960: Add compile check to FindEGL

[Ben Cooksley]

bcooksley added a comment.


/usr/local/bin/gmake -f CMakeFiles/cmTC_fd24d.dir/build.make 
CMakeFiles/cmTC_fd24d.dir/build
gmake[1]: Entering directory 
'/usr/home/jenkins/kwayland/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_fd24d.dir/src.cxx.o
/usr/bin/c++   -I/usr/local/include/EGL  -DHAVE_EGL   -o 
CMakeFiles/cmTC_fd24d.dir/src.cxx.o -c 
/usr/home/jenkins/kwayland/build/CMakeFiles/CMakeTmp/src.cxx
/usr/home/jenkins/kwayland/build/CMakeFiles/CMakeTmp/src.cxx:2:10: fatal 
error: 'EGL/egl.h' file not found
#include 
 ^~~
1 error generated.
gmake[1]: *** [CMakeFiles/cmTC_fd24d.dir/build.make:66: 
CMakeFiles/cmTC_fd24d.dir/src.cxx.o] Error 1
gmake[1]: Leaving directory 
'/usr/home/jenkins/kwayland/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:121: cmTC_fd24d/fast] Error 2
  
  The real issue here appears to be that PkgConfig information on include paths 
is being ignored by CMake (because it's right there):
  
[jenkins@freebsd-node1 ~/kwayland/build]$ cat CMakeCache.txt  | grep -i EGL
EGL_INCLUDE_DIR:PATH=/usr/local/include/EGL
EGL_LIBRARY:FILEPATH=/usr/local/lib/libEGL.so

KF5WaylandServer_LIB_DEPENDS:STATIC=general;Qt5::Gui;general;Wayland::Server;general;EGL::EGL;general;Qt5::Concurrent;
pkgcfg_lib_PKG_EGL_EGL:FILEPATH=/usr/local/lib/libEGL.so
//ADVANCED property for variable: EGL_INCLUDE_DIR
EGL_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: EGL_LIBRARY
EGL_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: HAVE_EGL
HAVE_EGL-ADVANCED:INTERNAL=1
//Test HAVE_EGL
HAVE_EGL:INTERNAL=

PKG_EGL_CFLAGS:INTERNAL=-I/usr/local/include;-I/usr/local/include/libdrm;-D_THREAD_SAFE;-pthread
PKG_EGL_CFLAGS_I:INTERNAL=
PKG_EGL_CFLAGS_OTHER:INTERNAL=-D_THREAD_SAFE;-pthread
PKG_EGL_FOUND:INTERNAL=1
PKG_EGL_INCLUDEDIR:INTERNAL=/usr/local/include
PKG_EGL_INCLUDE_DIRS:INTERNAL=/usr/local/include;/usr/local/include/libdrm
PKG_EGL_LDFLAGS:INTERNAL=-L/usr/local/lib;-lEGL
PKG_EGL_LDFLAGS_OTHER:INTERNAL=
PKG_EGL_LIBDIR:INTERNAL=/usr/local/lib
PKG_EGL_LIBRARIES:INTERNAL=EGL
PKG_EGL_LIBRARY_DIRS:INTERNAL=/usr/local/lib
PKG_EGL_LIBS:INTERNAL=
PKG_EGL_LIBS_L:INTERNAL=
PKG_EGL_LIBS_OTHER:INTERNAL=
PKG_EGL_LIBS_PATHS:INTERNAL=
PKG_EGL_PREFIX:INTERNAL=/usr/local

PKG_EGL_STATIC_CFLAGS:INTERNAL=-I/usr/local/include;-I/usr/local/include/libdrm;-D_THREAD_SAFE;-pthread
PKG_EGL_STATIC_CFLAGS_I:INTERNAL=
PKG_EGL_STATIC_CFLAGS_OTHER:INTERNAL=-D_THREAD_SAFE;-pthread

PKG_EGL_STATIC_INCLUDE_DIRS:INTERNAL=/usr/local/include;/usr/local/include/libdrm

PKG_EGL_STATIC_LDFLAGS:INTERNAL=-L/usr/local/lib;-lEGL;-lm;-lpthread;-pthread;-L/usr/local/lib;-ldrm;-lX11;-pthread;-L/usr/local/lib;-lxcb;-pthread;-lXau;-L/usr/local/lib;-lX11;-pthread;-L/usr/local/lib;-lxcb;-pthread;-lXau;-lXdamage;-L/usr/local/lib;-lX11;-pthread;-L/usr/local/lib;-lxcb;-pthread;-lXau;-L/usr/local/lib;-lX11;-pthread;-L/usr/local/lib;-lxcb;-pthread;-lXau;-L/usr/local/lib;-lX11;-pthread;-L/usr/local/lib;-lxcb;-pthread;-lXau;-lXfixes;-L/usr/local/lib;-pthread;-L/usr/local/lib;-lxcb;-pthread;-lXau;-lX11-xcb;-lX11;-pthread;-L/usr/local/lib;-pthread;-lXau;-pthread;-lXau;-lxcb;-pthread;-lXau;-lxcb-glx;-L/usr/local/lib;-lxcb;-pthread;-lXau;-lxcb-dri2;-L/usr/local/lib;-lxcb;-pthread;-lXau;-lXxf86vm;-L/usr/local/lib;-lX11;-pthread;-L/usr/local/lib;-lxcb;-pthread;-lXau;-lXext;-L/usr/local/lib;-lX11;-pthread;-L/usr/local/lib;-lxcb;-pthread;-lXau;-lXdmcp

PKG_EGL_STATIC_LDFLAGS_OTHER:INTERNAL=-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread;-pthread
PKG_EGL_STATIC_LIBDIR:INTERNAL=

PKG_EGL_STATIC_LIBRARIES:INTERNAL=EGL;m;pthread;drm;X11;xcb;Xau;X11;xcb;Xau;Xdamage;X11;xcb;Xau;X11;xcb;Xau;X11;xcb;Xau;Xfixes;xcb;Xau;X11-xcb;X11;Xau;Xau;xcb;Xau;xcb-glx;xcb;Xau;xcb-dri2;xcb;Xau;Xxf86vm;X11;xcb;Xau;Xext;X11;xcb;Xau;Xdmcp

PKG_EGL_STATIC_LIBRARY_DIRS:INTERNAL=/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib;/usr/local/lib
PKG_EGL_STATIC_LIBS:INTERNAL=
PKG_EGL_STATIC_LIBS_L:INTERNAL=
PKG_EGL_STATIC_LIBS_OTHER:INTERNAL=
PKG_EGL_STATIC_LIBS_PATHS:INTERNAL=
PKG_EGL_VERSION:INTERNAL=18.3.2
PKG_EGL_egl_INCLUDEDIR:INTERNAL=
PKG_EGL_egl_LIBDIR:INTERNAL=
PKG_EGL_egl_PREFIX:INTERNAL=
PKG_EGL_egl_VERSION:INTERNAL=
__pkg_config_arguments_PKG_EGL:INTERNAL=QUIET;egl
__pkg_config_checked_PKG_EGL:INTERNAL=1

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18960

To: hausmann, vkrause, apol
Cc: 

Re: ECM tests not run by CI (Re: KDE Frameworks 5.55.0)

[Ben Cooksley]

On Sun, Feb 10, 2019 at 2:13 AM David Faure  wrote:
>
> On samedi 9 février 2019 13:48:59 CET David Faure wrote:
> > On samedi 9 février 2019 11:25:20 CET Rik Mills wrote:
> > > I note that the KDE CI does not seem to run the tests at all?
> >
> > Indeed. I looked into it, and here's the reason why:
> >
> > [ci-tooling repo]
> > commit 45ff1bc4ecb18ad71ad0570f7e838d1ae7cab2e2
> > Author: Ben Cooksley 
> > Date:   Wed Sep 27 22:04:05 2017 +1300
> >
> > Revoke test execution for extra-cmake-modules across all platforms.
> > The tests in their current condition are incompatible with being run
> > prior to installation
>
> Ben, does that mean a simple solution would be to apply the "make install
> before running tests" principle to ECM, like we used to do (before I asked you
> to change it for all frameworks, not thinking about the ECM special case), and
> like we still do for applications (I think)?

ECM originally worked fine with tests-before-install but broke when
the ECMToolchainAndroidTest was introduced.
It fails with the following (according to mails at the time anyway):

+ python3 -u ci-tooling/helpers/install-build.py --product Frameworks
--project extra-cmake-modules --branchGroup kf5-qt5 --platform
XenialQt5.7 --installTo /home/jenkins/install-prefix/ --divertTo
/home/jenkins/workspace/Frameworks extra-cmake-modules kf5-qt5
XenialQt5.7/install-divert/
tests/ECMToolchainAndroidTest/CMakeFiles/dummy.dir/build.make:52:
CMakeFiles/dummy.dir/depend.make: No such file or directory
tests/ECMToolchainAndroidTest/CMakeFiles/dummy.dir/build.make:55:
CMakeFiles/dummy.dir/progress.make: No such file or directory
tests/ECMToolchainAndroidTest/CMakeFiles/dummy.dir/build.make:58:
CMakeFiles/dummy.dir/flags.make: No such file or directory
make[2]: *** No rule to make target 'CMakeFiles/dummy.dir/flags.make'. Stop.
CMakeFiles/Makefile2:205: recipe for target
'tests/ECMToolchainAndroidTest/CMakeFiles/dummy.dir/all' failed
make[1]: *** [tests/ECMToolchainAndroidTest/CMakeFiles/dummy.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2

In theory we could change the system to do ECM tests after the install
phase though yes (would need infrastructural changes in the CI tooling
to support project specific pipelines, but that shouldn't be too
complex)

>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>

Cheers,
Ben

D18547: Don't enable -Wzero-as-null-pointer-constant on apple clang

[Ben Cooksley]

bcooksley added a comment.


  This change is somewhat urgent - as can be seen at 
https://binary-factory.kde.org/view/MacOS/ all Mac builds are currently broken 
due to this issue.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18547

To: vonreth, aacid, apol, dfaure, rjvbb, bcooksley
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D15068: Bindings: Correct handling of sources containing utf-8

[Ben Cooksley]

bcooksley added a comment.


  The code itself looks fine to me - the change on line 752 is to allow 
handling of macOS / Windows line endings in addition to just Unix line endings 
I presume?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D15068

To: bruns, #frameworks
Cc: bcooksley, jtamate, kde-frameworks-devel, kde-buildsystem, michaelh, 
ngraham, bruns

Re: ECM Behaviour: Setting QT_PLUGIN_PATH on Windows

[Ben Cooksley]

On Sat, 8 Sep 2018, 20:12 David Faure,  wrote:

> On vendredi 31 août 2018 10:50:53 CEST Ben Cooksley wrote:
> > On Tue, Aug 28, 2018 at 10:35 PM Ben Cooksley  wrote:
> > > Hi all,
> >
> > Hi all,
> >
> > > We currently have a severe bug in ECM's AddTest macro due to it's
> > > behaviour around the setting of QT_PLUGIN_PATH. On Windows it would
> > > appear that the code in ECMAddTest mangles the environment variable,
> > > removing crucial paths that the CI system includes within this
> > > variable which are needed for applications and tests to function.
> > >
> > > As a consequence of this, several projects tests are broken, and some
> > > of these only fail by timeout. This has the effect of blocking Windows
> > > CI builders for several hours in some instances simply due to tests
> > > that are hanging and timing out as a result of being unable to load
> > > plugins.
> > >
> > > Can we please either short circuit this logic (and not try to set
> > > QT_PLUGIN_PATH on Windows) or figure out the correct logic to be used
> > > in this instance?
> > >
> > > My suspicion is that CMake treats ';' specially, which means that when
> > > the macro re-includes the existing content of the variable it gets
> > > mangled by CMake, resulting in the entire content of that variable
> > > being rendered unreadable.
> > >
> > > Alternatively, CMAKE_LIBRARY_OUTPUT_DIRECTORY could have a trailing
> > > backslash, which has certainly caused issues elsewhere.
> >
> > Based on the lack of response to this, along with my earlier mail to
> > k-f-d 7 days ago it doesn't look like anyone's going to pick this up.
> >
> > As this issue is causing test breakages on the CI system including
> > tying up valuable builder time for extraordinarily excessive amounts
> > of time, i've taken a sledgehammer to the offending code in ECM.
>
> Is there any indication that this code was misbehaving on Unix as well?
> I'm surprised that you took out everything, not just the Windows case.
>

As far as I've seen it hasn't caused any issues on Unix so it should be
fine to restore there.

I disabled it for all as a precautionary measure as I wasn't sure if it was
causing issues on Unix systems as well.

Cheers,
Ben


> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>

D15070: Bindings: Query the install directory from python

[Ben Cooksley]

bcooksley added a comment.


  We could, however that would not help people installing it as a regular user, 
rather than as root.
  If I run this right now, as an unprivileged user, I get the following path 
returned:
  
>>> sysconfig.get_python_lib( plat_specific=True,standard_lib=False )
'/usr/lib/python2.7/dist-packages'
  
  This will break installation for those doing development installations.
  
  If instead the code were to take CMAKE_INSTALL_PREFIX into account (which it 
should) then we get a valid result:
  
>>> sysconfig.get_python_lib( plat_specific=True,standard_lib=False, 
prefix="/some/path" )

Note: i'm aware of ~/.local/ and virtualenv's, however those not working on 
Python bindings may just prefer to set PYTHONPATH much like they already set 
PATH - especially if they have multiple installations they switch between 
(different Frameworks versions for instance).
'/some/path/lib/python2.7/site-packages'
  
  Note that it's up to the user to set PYTHONPATH properly if they're 
installing outside the usual directories searched by Python.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D15070

To: bruns, #frameworks
Cc: bcooksley, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D8256: Add _XOPEN_SOURCE to C definitions

[Ben Cooksley]

bcooksley added subscribers: FreeBSD, bcooksley.
bcooksley added a comment.


  This change appears to have resulted in a severe regression of builds on 
FreeBSD.
  Any ideas?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D8256

To: awilcox, alexmerry, dfaure
Cc: bcooksley, #freebsd, kde-frameworks-devel, kde-buildsystem, mpyne, dfaure, 
michaelh, ngraham, bruns

Re: ECM Behaviour: Setting QT_PLUGIN_PATH on Windows

[Ben Cooksley]

On Tue, Aug 28, 2018 at 10:35 PM Ben Cooksley  wrote:
>
> Hi all,

Hi all,

>
> We currently have a severe bug in ECM's AddTest macro due to it's
> behaviour around the setting of QT_PLUGIN_PATH. On Windows it would
> appear that the code in ECMAddTest mangles the environment variable,
> removing crucial paths that the CI system includes within this
> variable which are needed for applications and tests to function.
>
> As a consequence of this, several projects tests are broken, and some
> of these only fail by timeout. This has the effect of blocking Windows
> CI builders for several hours in some instances simply due to tests
> that are hanging and timing out as a result of being unable to load
> plugins.
>
> Can we please either short circuit this logic (and not try to set
> QT_PLUGIN_PATH on Windows) or figure out the correct logic to be used
> in this instance?
>
> My suspicion is that CMake treats ';' specially, which means that when
> the macro re-includes the existing content of the variable it gets
> mangled by CMake, resulting in the entire content of that variable
> being rendered unreadable.
>
> Alternatively, CMAKE_LIBRARY_OUTPUT_DIRECTORY could have a trailing
> backslash, which has certainly caused issues elsewhere.

Based on the lack of response to this, along with my earlier mail to
k-f-d 7 days ago it doesn't look like anyone's going to pick this up.

As this issue is causing test breakages on the CI system including
tying up valuable builder time for extraordinarily excessive amounts
of time, i've taken a sledgehammer to the offending code in ECM.

It should remain disabled until a proper solution can be found.

>
> Thanks,
> Ben

Regards,
Ben

D15070: Bindings: Query the install directory from python

[Ben Cooksley]

bcooksley added a comment.


  Please ensure that wherever it is installed to ends up within 
CMAKE_INSTALL_PREFIX otherwise this will end up failing on the CI system.
  
  The CI system takes care of setting PYTHONPATH accordingly to ensure 
resources are found.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D15070

To: bruns, #frameworks
Cc: bcooksley, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D11176: Don't call PythonInterp.cmake in KF5I18NMacros.

[Ben Cooksley]

bcooksley added a comment.
Restricted Application edited subscribers, added: kde-frameworks-devel; 
removed: Frameworks.


  This change has broken the build of all projects that make use of pmap 
resources on Windows, as the Python path at build time is not necessarily the 
path at install time (and it definitely not on the Binary Factory nodes)
  In particular it breaks KGeography - see 
https://binary-factory.kde.org/job/KGeography_Nightly_win32/112/console

REPOSITORY
  R249 KI18n

REVISION DETAIL
  https://phabricator.kde.org/D11176

To: cgiboudeaux
Cc: bcooksley, kde-frameworks-devel, sitter, dfaure, #build_system, michaelh, 
ngraham, bruns, #frameworks

D9299: Introduce INSTALL_PREFIX_SCRIPT to easily set up prefixes

[Ben Cooksley]

bcooksley added a comment.


  Depending on the end goal of this you may wish to also set the following 
environment variables:
  
CMAKE_PREFIX_PATH: to help guide CMake to look here in addition to system 
prefixes
PKG_CONFIG_PATH: to help pkg-config find *.pc files
QMAKEFEATURES: to help qmake find *.pri files
  
  Details on how those need to be used are documented in the CI environment 
management code at 
https://cgit.kde.org/sysadmin/ci-tooling.git/tree/helpers/helperslib/EnvironmentHandler.py

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9299

To: apol, #frameworks, sitter
Cc: bcooksley, ngraham, sitter, cgiboudeaux, #build_system

D8979: ecm_add_test: Use proper path sep on Windows

[Ben Cooksley]

bcooksley accepted this revision.
bcooksley added a comment.


  Looks fine to me.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8979

To: kfunk, dfaure, cgiboudeaux, bcooksley
Cc: #windows, #frameworks, #build_system

T6480: Some calligra tests fail

[Ben Cooksley]

bcooksley added a comment.


  No worries

TASK DETAIL
  https://phabricator.kde.org/T6480

To: danders, bcooksley
Cc: bcooksley, #build_system, danders, sysadmin, scarlettclark, blazquez

T6480: Some calligra tests fail

[Ben Cooksley]

bcooksley added a comment.


  I suspect that's a bug in your script as there is a space in the workspace 
directory used by the CI system.
  Can you check all places where paths are inserted are quoted?

TASK DETAIL
  https://phabricator.kde.org/T6480

To: bcooksley
Cc: bcooksley, #build_system, danders, sysadmin, scarlettclark, blazquez

T6480: Some calligra tests fail

[Ben Cooksley]

bcooksley moved this task from External: Active to External: Awaiting Response 
on the Sysadmin board.
bcooksley added a comment.


  Please provide more detail as to the exact tests which are failing (links to 
build.kde.org would be great)

TASK DETAIL
  https://phabricator.kde.org/T6480

WORKBOARD
  https://phabricator.kde.org/project/board/4/

To: bcooksley
Cc: bcooksley, #build_system, danders, sysadmin, scarlettclark, blazquez

D6073: Don't enable strict iterators on MSVC

[Ben Cooksley]

bcooksley abandoned this revision.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D6073

To: bcooksley, kfunk
Cc: kfunk, arrowdodger, #frameworks, #build_system

D6073: Don't enable strict iterators on MSVC

[Ben Cooksley]

bcooksley created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.

REVISION SUMMARY
  Currently we've found that strict iterators as available in MSVC, with 
certain codebases such as Threadweaver cause breakages to show up within Qt 
itself (in 5.7 at least).
  
  See 
https://build-sandbox.kde.org/view/Frameworks/job/Frameworks%20threadweaver%20kf5-qt5%20WindowsQt5.7/4/consoleText
 for the build log.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D6073

AFFECTED FILES
  kde-modules/KDEFrameworkCompilerSettings.cmake

To: bcooksley
Cc: #frameworks, #build_system

Re: Extremely poor quality of KWave's build system

[Ben Cooksley]

On Thu, May 25, 2017 at 6:50 AM, Thomas Eschenbacher
<thomas.eschenbac...@gmx.de> wrote:
> Hi all,
>
> I have no idea what all these complains are about. Nobody ever
> complained about the quality of Kwave's build system in the last 18
> years in such a way and nobody had a serious problem with the dependencies.

Please observe the behaviour of KWave's configuration process when one
or more of those dependencies are not installed.

>
> The dependencies are well documented in the README file, in the online
> documentation (docbook), they are clearly visible for any developer with
> average skills in the Gentoo ebuild, in the RPM spec file...
> what else should I do to prevent you from failing? If you would have
> read any single line of the input files mentioned above then you would
> not have failed.

As part of making the CI system work I'm running a very large number
of builds (essentially every single entry at
https://build-sandbox.kde.org/)
Therefore looking into files contained within each project's
repository isn't really a scalable approach (we're talking 100+ builds
here).

I rely on the output of CMake entirely and on it behaving properly and
imagine packagers are in a similar situation.

>
> The only thing that comes into my mind is "RTFM" !!!
>
> I would surely have reworked things if someone would have asked me
> *POLITELY* and with reasonable arguments. But if I only get comments
> like "fuck you, all your stuff sucks" - I WILL DEFINITELY NOT CHANGE ANY
> SINGLE LINE FOR YOU !!!

Sorry if that's how you interpreted it.
My mail was based off my experiences and the comments of another
developer who looked at the CMake code when I mentioned the issues I
was having with KWave.

I've spent quite a few hours fighting with KWave's build system due to
these issues.

>
> I fully agree to Albert.
>
> Probably you Ben are just the wrong person for performing such tasks and
> should be removed from that "build system" team...
>
> regards,
>Thomas

Cheers,
Ben

>
> Albert Astals Cid wrote:
>
>> El dimarts, 23 de maig de 2017, a les 19:53:29 CEST, Ben Cooksley va 
>> escriure:
>>> Hi all,
>>>
>>> I've been working on the new CI system recently, and as part of this
>>> have run into a few issues with some projects. Most of these have been
>>> easily resolved.
>>>
>>> KWave however is another ball park entirely and has to date cost at
>>> least 5 base system image rebuilds (quite likely higher) and quite a
>>> bit of time. After all that I still haven't got it to pass the
>>> configure stage. This is due to it's build system failing immediately
>>> as soon as it fails to find a single dependency.
>>>
>>> This is improper behaviour for a build system, which should check for
>>> everything, then give a listing of hard required and suggested
>>> dependencies which are missing before bailing out. From what i'm told
>>> this is due to severe abuse of the FindPkgConfig() macro that CMake
>>> provides.
>>>
>>> Thomas, can you please (completely) rewrite the whole CMake build
>>> system KWave uses to behave correctly?
>>>
>>> I'm revoking KWave's CI privileges from this point forward as I don't
>>> want to waste any further time on this.
>>
>> Let me try to comment on the wording of this email first.
>>
>> I think this is not the correct way to handle the problem.
>>
>> If you can't get ultra-frustrated and then say "fuckit i'm banning you from
>> CI", that lowers a lot motivation on the other side because you didn't even
>> gave them the possibility of "defending" themselves.
>>
>> I think a more positive way would have been to stop before you get ultra-
>> frustrated and say something like "I can't get this to work, please have a
>> look, if this doesn't get fixed in X days we may have to think about removing
>> kwave from CI".
>>
>> In essence "it's the same", but wording matters.
>>
>> On the actual problem, as a workaround, have you tried "apt-get build-dep
>> kwave" or the "synonymous" command in whatever OS the image you're using has?
>>
>> Cheers,
>>   Albert
>>
>>>
>>> Regards,
>>> Ben Cooksley
>>> KDE Sysadmin
>>
>>
>
>
> --
> __
> Thomas Eschenbacher   <thomas.eschenbac...@gmx.de>

Re: Extremely poor quality of KWave's build system

[Ben Cooksley]

On Wed, May 24, 2017 at 9:37 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dimarts, 23 de maig de 2017, a les 19:53:29 CEST, Ben Cooksley va escriure:
>> Hi all,
>>
>> I've been working on the new CI system recently, and as part of this
>> have run into a few issues with some projects. Most of these have been
>> easily resolved.
>>
>> KWave however is another ball park entirely and has to date cost at
>> least 5 base system image rebuilds (quite likely higher) and quite a
>> bit of time. After all that I still haven't got it to pass the
>> configure stage. This is due to it's build system failing immediately
>> as soon as it fails to find a single dependency.
>>
>> This is improper behaviour for a build system, which should check for
>> everything, then give a listing of hard required and suggested
>> dependencies which are missing before bailing out. From what i'm told
>> this is due to severe abuse of the FindPkgConfig() macro that CMake
>> provides.
>>
>> Thomas, can you please (completely) rewrite the whole CMake build
>> system KWave uses to behave correctly?
>>
>> I'm revoking KWave's CI privileges from this point forward as I don't
>> want to waste any further time on this.
>
> Let me try to comment on the wording of this email first.

Sure.

>
> I think this is not the correct way to handle the problem.
>
> If you can't get ultra-frustrated and then say "fuckit i'm banning you from
> CI", that lowers a lot motivation on the other side because you didn't even
> gave them the possibility of "defending" themselves.

Fair enough.

>
> I think a more positive way would have been to stop before you get ultra-
> frustrated and say something like "I can't get this to work, please have a
> look, if this doesn't get fixed in X days we may have to think about removing
> kwave from CI".
>
> In essence "it's the same", but wording matters.
>
> On the actual problem, as a workaround, have you tried "apt-get build-dep
> kwave" or the "synonymous" command in whatever OS the image you're using has?

I generally tend to avoid those commands as they usually want to drag
in all of Frameworks and other KDE supplied dependencies.
One tends to end up cherry picking just a couple of packages from the
list which isn't always that easy (KDE packages tend to dominate the
list) and ends up taking longer.
This image was a Fedora one for those interested.

>
> Cheers,
>   Albert
>
>>
>> Regards,
>> Ben Cooksley
>> KDE Sysadmin
>
>

Cheers,
Ben

Re: Extremely poor quality of KWave's build system

[Ben Cooksley]

On Wed, May 24, 2017 at 8:36 PM, Luca Beltrame  wrote:
> Il giorno Tue, 23 May 2017 23:37:25 +0200
> Albert Astals Cid  ha scritto:
>
>> On the actual problem, as a workaround, have you tried "apt-get
>> build-dep kwave" or the "synonymous" command in whatever OS the image
>> you're using has?
>
> My guess is that it would pull also the KDE software dependencies,
> which is something unwanted as they're handled by the CI itself.

Yes, that's correct. We don't install anything that comes from
git.kde.org, to entirely eliminate the possibility that system
binaries are used instead of binaries provided by the CI system
itself.

>
> But a workaround would be to watch the output and grab all non-KDE
> stuff there. (Not ideal, I know)

Yeah, that is an option. In some cases the list of Frameworks + Other
KDE packages (like ECM) makes sorting through such a list quite
formidable.
In many cases it's faster to just install what CMake is reporting as missing.

Cheers,
Ben

Extremely poor quality of KWave's build system

[Ben Cooksley]

Hi all,

I've been working on the new CI system recently, and as part of this
have run into a few issues with some projects. Most of these have been
easily resolved.

KWave however is another ball park entirely and has to date cost at
least 5 base system image rebuilds (quite likely higher) and quite a
bit of time. After all that I still haven't got it to pass the
configure stage. This is due to it's build system failing immediately
as soon as it fails to find a single dependency.

This is improper behaviour for a build system, which should check for
everything, then give a listing of hard required and suggested
dependencies which are missing before bailing out. From what i'm told
this is due to severe abuse of the FindPkgConfig() macro that CMake
provides.

Thomas, can you please (completely) rewrite the whole CMake build
system KWave uses to behave correctly?

I'm revoking KWave's CI privileges from this point forward as I don't
want to waste any further time on this.

Regards,
Ben Cooksley
KDE Sysadmin

D5489: Sanitizers: Don't use GCC-like flags for e.g. MSVC

[Ben Cooksley]

bcooksley accepted this revision.
bcooksley added a comment.


  Looks good to me - thanks for taking this on, it'll make getting CI working 
for Windows much easier.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5489

To: kfunk, aacid, bcooksley
Cc: #frameworks, #build_system

Re: Review Request 129117: Adds KF5Purpose and Kirigami to the default build

[Ben Cooksley]

> On Nov. 5, 2016, 9:14 a.m., David Faure wrote:
> > Ship It!
> 
> David Faure wrote:
> I withdraw my approval. Please revert.
> I just noticed that these modules have been added for the "frameworks" 
> module-set. This doesn't make sense, they are not part of frameworks. When I 
> type "kdesrc-build frameworks" I expect that only the real KF5 modules will 
> be built.
> 
> purpose is in playground/libs. If it's needed by kamoso, then it should 
> be moved to extragear/libs and added to kf5-extragear-build-include. Follow 
> the review process for this to happen.
> 
> kirigami is in extragear/libs. If it's required by discover, it should be 
> moved to kde/workspace, and then it can be added in 
> kf5-workspace-build-include (ask the plasma people if they agree, then file a 
> sysadmin request for the move). If it's also needed by applications, then it 
> needs to be turned into a proper framework.
> 
> Nicolás Alvarez wrote:
> kamoso in extragear depending on purpose in playground does seem weird, 
> and maybe purpose should be moved to extragear.
> 
> However, I don't think a library (kirigami) that is needed by 
> applications should be forced to follow the KF5 release schedule. In terms of 
> versioning, it should be handled the same as a third-party library. They can 
> release when they want, and applications can bump the dependency when they 
> need to.

I'm with David here. Libraries should also stop abusing KF5* - that prefix is 
exclusively reserved for Frameworks.

Due to the manner in which development code often depends on other development 
code - especially for libraries such as Purpose - i'm strongly in favour of 
Workspace/Applications only being allowed to depend on libraries in the same 
release unit or Frameworks (for libraries maintained by KDE anyway).

In any case, depending on Playground should definitely be forbidden (you 
shouldn't be releasing code from Playground anyway).


- Ben


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129117/#review100589
---


On Nov. 7, 2016, 9:39 a.m., Tomaz  Canabrava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129117/
> ---
> 
> (Updated Nov. 7, 2016, 9:39 a.m.)
> 
> 
> Review request for Build System.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> Kirigami is now needed to run discover, so it should be build
> Purpose is needed by at least kamoso.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> Add Kamoso to the buildsystem.
> 
> Kamoso was missing from kdegraphics.
> 
> Signed-off-by: Tomaz Canabrava 
> 
> 
> Diffs
> -
> 
>   kf5-applications-build-include f53c0233ba46322829076db3437cf9c62a65ff8e 
>   kf5-frameworks-build-include a88498e3248262d2e1fddacd726e1ef06a3ac1e4 
> 
> Diff: https://git.reviewboard.kde.org/r/129117/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tomaz  Canabrava
> 
>

Re: Review Request 128779: Teach KDECompilerSettings about clang-cl, a mode of Clang compiler that simulates MSVC.

[Ben Cooksley]

> On Oct. 8, 2016, 9:09 a.m., Ben Cooksley wrote:
> > This code as it stands failed on the CI system and proceeded to break all 
> > Frameworks builds.
> > Please re-review the code and ensure that no action is taken for GCC based 
> > compilers.
> 
> Gleb Popov wrote:
> I'm terribly sorry for the breakage, the change looked innocent.
> 
> Could you please help me locate corresponding build log? I've got lost on 
> Jenkins. I've found this, but it doesn't seem to be related to my commit: 
> https://build.kde.org/job/extra-cmake-modules%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/33/console

That is the affected ECM build log yes.


- Ben


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128779/#review99843
---


On Oct. 8, 2016, 6:41 a.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128779/
> ---
> 
> (Updated Oct. 8, 2016, 6:41 a.m.)
> 
> 
> Review request for Extra Cmake Modules and kdewin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> By simply using `if(CMAKE_COMPILER_ID STREQUAL "Clang")` check is not enough 
> for clang-cl, as it turns on various '-style' flags and omits MSVC's '/style' 
> flags.
> 
> With this patch i managed to compile much of KF5 up to konversation and kate.
> 
> Known problems: `-std=gnu++98` flag is still appended, but i wasn't able to 
> figure out why.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake dfa29f7 
>   kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 
> 
> Diff: https://git.reviewboard.kde.org/r/128779/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

Re: Review Request 128779: Teach KDECompilerSettings about clang-cl, a mode of Clang compiler that simulates MSVC.

[Ben Cooksley]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128779/#review99843
---



This code as it stands failed on the CI system and proceeded to break all 
Frameworks builds.
Please re-review the code and ensure that no action is taken for GCC based 
compilers.

- Ben Cooksley


On Oct. 8, 2016, 6:41 a.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128779/
> ---
> 
> (Updated Oct. 8, 2016, 6:41 a.m.)
> 
> 
> Review request for Extra Cmake Modules and kdewin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> By simply using `if(CMAKE_COMPILER_ID STREQUAL "Clang")` check is not enough 
> for clang-cl, as it turns on various '-style' flags and omits MSVC's '/style' 
> flags.
> 
> With this patch i managed to compile much of KF5 up to konversation and kate.
> 
> Known problems: `-std=gnu++98` flag is still appended, but i wasn't able to 
> figure out why.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake dfa29f7 
>   kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 
> 
> Diff: https://git.reviewboard.kde.org/r/128779/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

ECM Breakage: Compilation failure for GCC

[Ben Cooksley]

Hi all,

It appears that commit 4b8e8dcc8856d8f438860783e7641d02d1c05630 to ECM
broke the whole CI system for all Qt 5 / Frameworks builds.

I've therefore reverted it.

Regards,
Ben Cooksley
KDE Sysadmin

Re: The return of ASAN issues

[Ben Cooksley]

On Mon, Jun 13, 2016 at 6:25 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dimarts, 31 de maig de 2016, a les 18:49:29 CEST, Ben Cooksley va escriure:
>> On Tue, May 31, 2016 at 9:36 AM, Albert Astals Cid <aa...@kde.org> wrote:
>> > El dilluns, 30 de maig de 2016, a les 19:42:38 CEST, Ben Cooksley va
> escriure:
>> >> Hi all,
>> >>
>> >> As you may recall, some time ago the CI scripts were adapted to
>> >> forcibly inject ASAN into all test processes launched on the CI system
>> >> to fix Marble's tests, as Marble does not use ECM and thus does not
>> >> enable ASAN as a result.
>> >>
>> >> Unfortunately this has bad effects with certain processes,
>> >> particularly Java based ones. This causes the tests of other projects
>> >> to fail as a result with segmentation faults, as they're incompatible
>> >> with forced ASAN injection - they have to actually be built with ASAN
>> >> for it to work.
>> >>
>> >> Can someone please investigate another solution?
>> >
>> > I know it's a workaround, but given Marble is a bit of an unique snowflake
>> > in that it doesn't want to use ECM because it adds 0.3MB of dependencies,
>> > can't we just apply the LD_PRELOAD workaround on the "marble" job level
>> > (afaik we can do those things)?
>>
>> With a maintenance cost. But yes, it could be done.
>
> A very low maitenance cost IMHO compared to your suggestion, half proof is
> that you got someone that volunteered to implement my suggestion (me and i
> think Friedrich volunteered for something similar) while noone volunteered to
> play with the cmake files.
>
> As I see it what you're asking for is more correct but has a much bigger
> coding cost and the solution to applying the workaround only to marble is
> probably a 5 minute change that alls us to move forward.

Let's hope this isn't a slippery slope. Special cases have a nasty
habit of accumulating.
I've implemented this now. In the event other projects need this sort
of treatment for $whateverReason we'll need to revisit doing this
properly in some form or another.

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> > What you suggest would be superb correct-ness wise but it doesn't seem the
>> > more effort/result solution.
>>
>> It would also fix anyone who has compiled Frameworks with ASAN and
>> needs to use a build system from elsewhere which does not use ECM
>> (Such as QMake for instance, although why you'd use ASAN in Frameworks
>> and not your app is another thing altogether of course)
>>
>> > Cheers,
>> >
>> >   Albert
>>
>> Regards,
>> Ben
>>
>> >> As ASAN is contagious, I would suggest that any Framework which is
>> >> compiled using ASAN have adjustments made to it's *Config.cmake files
>> >> to ensure linking for any binary/library built with it is setup
>> >> properly. I've no idea how complicated that is to setup though.
>> >>
>> >> This would fix Marble's tests while allowing Skrooge's tests that
>> >> depend on Java to be unaffected (and I considered the original fix to
>> >> inject ASAN a bit hackish, so i'm not surprised it's had casualties)
>> >>
>> >> Cheers,
>> >> Ben
>> >> ___
>> >> Kde-frameworks-devel mailing list
>> >> kde-frameworks-de...@kde.org
>> >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>>
>> ___
>> Kde-frameworks-devel mailing list
>> kde-frameworks-de...@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: The return of ASAN issues

[Ben Cooksley]

On Tue, May 31, 2016 at 9:36 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dilluns, 30 de maig de 2016, a les 19:42:38 CEST, Ben Cooksley va escriure:
>> Hi all,
>>
>> As you may recall, some time ago the CI scripts were adapted to
>> forcibly inject ASAN into all test processes launched on the CI system
>> to fix Marble's tests, as Marble does not use ECM and thus does not
>> enable ASAN as a result.
>>
>> Unfortunately this has bad effects with certain processes,
>> particularly Java based ones. This causes the tests of other projects
>> to fail as a result with segmentation faults, as they're incompatible
>> with forced ASAN injection - they have to actually be built with ASAN
>> for it to work.
>>
>> Can someone please investigate another solution?
>
> I know it's a workaround, but given Marble is a bit of an unique snowflake in
> that it doesn't want to use ECM because it adds 0.3MB of dependencies, can't
> we just apply the LD_PRELOAD workaround on the "marble" job level (afaik we
> can do those things)?

With a maintenance cost. But yes, it could be done.

>
> What you suggest would be superb correct-ness wise but it doesn't seem the
> more effort/result solution.

It would also fix anyone who has compiled Frameworks with ASAN and
needs to use a build system from elsewhere which does not use ECM
(Such as QMake for instance, although why you'd use ASAN in Frameworks
and not your app is another thing altogether of course)

>
> Cheers,
>   Albert

Regards,
Ben

>
>>
>> As ASAN is contagious, I would suggest that any Framework which is
>> compiled using ASAN have adjustments made to it's *Config.cmake files
>> to ensure linking for any binary/library built with it is setup
>> properly. I've no idea how complicated that is to setup though.
>>
>> This would fix Marble's tests while allowing Skrooge's tests that
>> depend on Java to be unaffected (and I considered the original fix to
>> inject ASAN a bit hackish, so i'm not surprised it's had casualties)
>>
>> Cheers,
>> Ben
>> ___
>> Kde-frameworks-devel mailing list
>> kde-frameworks-de...@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: The return of ASAN issues

[Ben Cooksley]

On Mon, May 30, 2016 at 10:51 PM, Friedrich W. H. Kossebau
<kosse...@kde.org> wrote:
> Hi,

Hi Friedrich,

>
> Am Montag, 30. Mai 2016, 19:42:38 CEST schrieb Ben Cooksley:
>> As you may recall, some time ago the CI scripts were adapted to
>> forcibly inject ASAN into all test processes launched on the CI system
>> to fix Marble's tests, as Marble does not use ECM and thus does not
>> enable ASAN as a result.
>>
>> Unfortunately this has bad effects with certain processes,
>> particularly Java based ones. This causes the tests of other projects
>> to fail as a result with segmentation faults, as they're incompatible
>> with forced ASAN injection - they have to actually be built with ASAN
>> for it to work.
>>
>> Can someone please investigate another solution?
>>
>> As ASAN is contagious, I would suggest that any Framework which is
>> compiled using ASAN have adjustments made to it's *Config.cmake files
>> to ensure linking for any binary/library built with it is setup
>> properly. I've no idea how complicated that is to setup though.
>
> It is not just "Framework" as in "KF5", but any lib (built on CI) which uses
> KDECompilerSettings.cmake (or ECMEnableSanitizers.cmake directly) and is used
> by other KDE projects (which includes even Phonon), right?

That is correct.

>
> Cheers
> Friedrich

Thanks,
Ben

> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

The return of ASAN issues

[Ben Cooksley]

Hi all,

As you may recall, some time ago the CI scripts were adapted to
forcibly inject ASAN into all test processes launched on the CI system
to fix Marble's tests, as Marble does not use ECM and thus does not
enable ASAN as a result.

Unfortunately this has bad effects with certain processes,
particularly Java based ones. This causes the tests of other projects
to fail as a result with segmentation faults, as they're incompatible
with forced ASAN injection - they have to actually be built with ASAN
for it to work.

Can someone please investigate another solution?

As ASAN is contagious, I would suggest that any Framework which is
compiled using ASAN have adjustments made to it's *Config.cmake files
to ensure linking for any binary/library built with it is setup
properly. I've no idea how complicated that is to setup though.

This would fix Marble's tests while allowing Skrooge's tests that
depend on Java to be unaffected (and I considered the original fix to
inject ASAN a bit hackish, so i'm not surprised it's had casualties)

Cheers,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [Digikam-devel] [Kde-pim] Akonadi Contact library: Targets not properly exported

[Ben Cooksley]

On Thu, Apr 28, 2016 at 11:32 PM, Aleix Pol <aleix...@kde.org> wrote:
> On Thu, Apr 28, 2016 at 8:28 AM, Ben Cooksley <bcooks...@kde.org> wrote:
>> On Thu, Apr 28, 2016 at 7:22 AM, Stephen Kelly <steve...@gmail.com> wrote:
>>> Ben Cooksley wrote:
>>>
>>>>> Has this issue been resolved somehow?
>>>>
>>>> Yes, the fault in Digikam's code has been resolved.
>>>> From what I understand it has something to do with some of the more
>>>> unusual CMake constructs which Digikam was using (and is a fault the
>>>> CMake developers have acknowledged but is apparently rather difficult
>>>> to fix)
>>>
>>> I'm curious, so I looked through some recent digikam commits but didn't find
>>> what you are referring to. Can someone point me to more information?
>>
>> Sure. This appears to be the relevant commit:
>> https://quickgit.kde.org/?p=digikam.git=commitdiff=f6e0fba7025fbbe5f9cd1d4fc8b16f88a5d0928e
>>
>> If you need more details I'll see what I can find.
>
> That commit looks wrong, if anything maybe AkonadiContacts should have
> become PUBLIC.

From what I understand, AkonadiContacts is fine - the bug is in CMake
not passing the targets automagic through the OBJECT construct Digikam
uses.

>
> Aleix

Cheers,
Ben

> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [Digikam-devel] [Kde-pim] Akonadi Contact library: Targets not properly exported

[Ben Cooksley]

On Wed, Apr 27, 2016 at 7:11 PM, Stephen Kelly <steve...@gmail.com> wrote:
> Ben Cooksley wrote:
>
>> It would be appreciated if you jointly investigated why this isn't
>> working.
>
> Hi,

Hi Stephen,

>
> Sorry for not being active on this before.
>
> I tried to build the akonadi parts of digikam master with akonadi-contacts
> from kdepimlibs, and it worked. I also notice that the build on b.k.o is not
> red and the #include seems to be as it has always been.
>
> Has this issue been resolved somehow?

Yes, the fault in Digikam's code has been resolved.
From what I understand it has something to do with some of the more
unusual CMake constructs which Digikam was using (and is a fault the
CMake developers have acknowledged but is apparently rather difficult
to fix)

>
> Thanks,
>
> Steve.

Cheers,
Ben

>
>
>
> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [Digikam-devel] [Kde-pim] Akonadi Contact library: Targets not properly exported

[Ben Cooksley]

On Sat, Apr 9, 2016 at 8:07 PM, Christophe Giboudeaux
<cgiboude...@gmx.com> wrote:
> On samedi 9 avril 2016 08:53:51 CEST Ben Cooksley wrote:
>> On Sat, Apr 9, 2016 at 12:38 AM, Gilles Caulier
>>
>> <caulier.gil...@gmail.com> wrote:
>> > Hi Scarlet,
>>
>> Hi GIlles, PIM developers,
>>
>> > -#include 
>> > +#include 
>> >
>> > This patch sound like a wrong way to handle frameworks header. After all i
>> > never use #include  syntax, and there is no reason to do it.
>> >
>> > Using the .h file instead the camelcase version is not a problem, but both
>> > cases must work well in client application.
>>
>> Can someone please investigate the issue within the Akonadi Contact library?
>> Assuming the part of Digikam which is trying to use this header is linking
>> to the appropriate library using the provided target, then this compilation
>> failure would indicate that targets are not being properly exported despite
>> appearing to be so.
>>
>
> To investigate the digikam issue, a failing build log with VERBOSE=1 would
> certainly help.

The relevant fragment is attached - a full VERBOSE=1 log for the
entire of Digikam up to the point where it fails would be many
megabytes in size (which is why they're not enabled on the CI system).

Cheers,
Ben

>
>
> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
>
/usr/bin/cmake -E cmake_progress_report /home/jenkins/digikam/build/CMakeFiles 
Building CXX object 
utilities/kdesupport/akonadi/CMakeFiles/akonadiiface_src.dir/akonadiiface.cpp.o
cd /home/jenkins/digikam/build/utilities/kdesupport/akonadi && /usr/bin/c++   
-DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_NO_CAST_FROM_BYTEARRAY 
-DQT_NO_URL_CAST_FROM_STRING -DQT_USE_FAST_OPERATOR_PLUS 
-DQT_USE_QSTRINGBUILDER -DTRANSLATION_DOMAIN=\"digikam\" -D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE -std=c++0x -Wall -Wextra -Wcast-align -Wchar-subscripts 
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor 
-Woverloaded-virtual -Werror=return-type  -std=c++0x -Wall -Wextra -Wcast-align 
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -fexceptions -fPIC 
-I/home/jenkins/digikam/build/utilities/kdesupport/akonadi 
-I/home/jenkins/digikam/utilities/kdesupport/akonadi 
-I/home/jenkins/digikam/app/date -I/home/jenkins/digikam/app/utils 
-I/home/jenkins/digikam/app/main -I/home/jenkins/digikam/app/items 
-I/home/jenkins/digikam/app/items/overlays -I/home/jenkins/digikam/app/filters 
-I/home/jenkins/digikam/app/views -I/home/jenkins/digikam/app/views/tableview 
-I/home/jenkins/digikam/app/dragdrop 
-I/home/jenkins/digikam/utilities/slideshow 
-I/home/jenkins/digikam/utilities/queuemanager/manager 
-I/home/jenkins/digikam/utilities/queuemanager/main 
-I/home/jenkins/digikam/utilities/queuemanager/basetools/transform 
-I/home/jenkins/digikam/utilities/queuemanager/basetools/convert 
-I/home/jenkins/digikam/utilities/queuemanager/basetools/metadata 
-I/home/jenkins/digikam/utilities/queuemanager/basetools/enhance 
-I/home/jenkins/digikam/utilities/queuemanager/basetools/filters 
-I/home/jenkins/digikam/utilities/queuemanager/basetools/color 
-I/home/jenkins/digikam/utilities/queuemanager/basetools/decorate 
-I/home/jenkins/digikam/utilities/queuemanager/basetools/custom 
-I/home/jenkins/digikam/utilities/queuemanager/views 
-I/home/jenkins/digikam/utilities/geolocation/geoiface 
-I/home/jenkins/digikam/utilities/geolocation/geoiface/backends 
-I/home/jenkins/digikam/utilities/geolocation/editor/bookmark 
-I/home/jenkins/digikam/utilities/geolocation/editor/backends 
-I/home/jenkins/digikam/utilities/geolocation/editor/reversegeocoding 
-I/home/jenkins/digikam/utilities/geolocation/editor/dialog 
-I/home/jenkins/digikam/utilities/geolocation/editor/items 
-I/home/jenkins/digikam/utilities/geolocation/editor/searches 
-I/home/jenkins/digikam/utilities/geolocation/editor/correlator 
-I/home/jenkins/digikam/utilities/geolocation/editor/dragdrop 
-I/home/jenkins/digikam/utilities/geolocation/mapsearches 
-I/home/jenkins/digikam/utilities/geolocation/geomapwrapper 
-I/home/jenkins/digikam/utilities/advancedrename/common 
-I/home/jenkins/digikam/utilities/advancedrename 
-I/home/jenkins/digikam/utilities/advancedrename/parser 
-I/home/jenkins/digikam/utilities/advancedrename/parser/modifiers 
-I/home/jenkins/digikam/utilities/advancedrename/parser/options 
-I/home/jenkins/digikam/utilities/advancedrename/parser/options/database 
-I/home/jenkins/digikam/utilities/advancedrename/parser/options/database/keys 
-I/home/jenkins/digikam/utilities/assistants/common 
-I/home/jenkins/digikam/utilities/assistants/calendar/wizard 
-I/

Re: [Digikam-devel] [Kde-pim] Akonadi Contact library: Targets not properly exported

[Ben Cooksley]

On Sat, Apr 9, 2016 at 12:38 AM, Gilles Caulier
<caulier.gil...@gmail.com> wrote:
> Hi Scarlet,

Hi GIlles, PIM developers,

>
> -#include 
> +#include 
>
> This patch sound like a wrong way to handle frameworks header. After all i
> never use #include  syntax, and there is no reason to do it.
>
> Using the .h file instead the camelcase version is not a problem, but both
> cases must work well in client application.

Can someone please investigate the issue within the Akonadi Contact library?
Assuming the part of Digikam which is trying to use this header is
linking to the appropriate library using the provided target, then
this compilation failure would indicate that targets are not being
properly exported despite appearing to be so.

It would be appreciated if you jointly investigated why this isn't working.

Also, PIM devs - you've broken your CI jobs with your version bump *again*.
Please check with dfaure on how he handles the Frameworks version
bumps - those don't experience these issues.

>
> Gilles Caulier

Regards,
Ben

>
> 2016-04-07 3:01 GMT+02:00 Scarlett Clark <scarlett.gately.cl...@gmail.com>:
>>
>> It has to do with /path/to/include/KF5/path/to/camelcase , the key is
>> actually the KF5 folder.
>> If I patch  include/KF5/Path/To/Camelcase file it works, however the camel
>> case file does not find its own header.
>>
>>
>> /srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/kde/kdepimlibs/inst/usr/include/KF5/Akonadi/Contact/ContactSearchJob:1:46:
>> fatal error: akonadi/contact/contactsearchjob.h: No such file or directory
>> 22:47:37 compilation terminated.
>>
>> I can only assume the KF5 folder is involved again. So I tried to add KF5
>> to the ecm_generate_headers(PREFIX) but that has the effect of lower case
>> kf5 which also does not work, obviously.
>>
>> So I turned back to Digikam and patched:
>>
>> -#include 
>> +#include 
>>
>> And finally we have a successful build.
>>
>>
>> https://build.kde.org/job/digikam%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/68/console
>>
>> I do notice KDE_INSTALL_INCLUDEDIR_KF5 in kdepimlibs is likely what puts
>> in this KF5 folder?
>>
>> I do not know who is responsible here, but someone needs to fix something
>> :) I have exhausted my current C++ skills to get this far lol.
>>
>> I have added digikam to the conversation.
>> Cheers,
>> Scarlett
>>
>>
>> On Thu, Mar 31, 2016 at 11:48 PM, Ben Cooksley <bcooks...@kde.org> wrote:
>>>
>>> On Thu, Mar 31, 2016 at 11:44 PM, Christophe Giboudeaux
>>> <cgiboude...@gmx.com> wrote:
>>> > On mercredi 30 mars 2016 20:19:29 CEST Ben Cooksley wrote:
>>> >> On Tue, Mar 29, 2016 at 10:46 PM, Sandro Knauß <skna...@kde.org>
>>> >> wrote:
>>> >>
>>> >> Those are the header generation and installation routines - which do
>>> >> indeed look.
>>> >> What is missing in this case is the include path specification for the
>>> >> KF5::AkonadiContact target which CMake provides.
>>> >>
>>> >
>>> > The exported target is correct.
>>> > From KF5AkonadiContactTargets.cmake :
>>> >
>>> > set_target_properties(KF5::AkonadiContact PROPERTIES
>>> > INTERFACE_INCLUDE_DIRECTORIES
>>> >  "${_IMPORT_PREFIX}/include/KF5/Akonadi/Contact;
>>> >   ${_IMPORT_PREFIX}/include/KF5;
>>> >   ${_IMPORT_PREFIX}/include/KF5/akonadi/contact;
>>> >   ${_IMPORT_PREFIX}/include/KF5"
>>> >   INTERFACE_LINK_LIBRARIES
>>> > "KF5::AkonadiCore;KF5::Contacts;Qt5::Widgets"
>>> > )
>>>
>>> Hmm, indeed that does look correct.
>>> I wonder why Digikam would fail to compile then:
>>>
>>> 19:24:09
>>> /home/jenkins/sources/digikam/kf5-qt5/utilities/kdesupport/akonadi/akonadiiface.cpp:47:44:
>>> fatal error: Akonadi/Contact/ContactSearchJob: No such file or
>>> directory
>>>
>>> Any ideas? (I assume Digikam is trying using to use AkonadiContact
>>> correctly)
>>>
>>> Cheers,
>>> Ben
>>>
>>> >
>>> > ___
>>> > Kde-buildsystem mailing list
>>> > Kde-buildsystem@kde.org
>>> > https://mail.kde.org/mailman/listinfo/kde-buildsystem
>>> >
>>> ___
>>> KDE PIM mailing list kde-...@kde.org
>>> https://mail.kde.org/mailman/listinfo/kde-pim
>>> KDE PIM home page at http://pim.kde.org/
>>
>>
>>
>> ___
>> Digikam-devel mailing list
>> digikam-de...@kde.org
>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>
>
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [Kde-pim] Akonadi Contact library: Targets not properly exported

[Ben Cooksley]

On Thu, Mar 31, 2016 at 11:44 PM, Christophe Giboudeaux
<cgiboude...@gmx.com> wrote:
> On mercredi 30 mars 2016 20:19:29 CEST Ben Cooksley wrote:
>> On Tue, Mar 29, 2016 at 10:46 PM, Sandro Knauß <skna...@kde.org> wrote:
>>
>> Those are the header generation and installation routines - which do
>> indeed look.
>> What is missing in this case is the include path specification for the
>> KF5::AkonadiContact target which CMake provides.
>>
>
> The exported target is correct.
> From KF5AkonadiContactTargets.cmake :
>
> set_target_properties(KF5::AkonadiContact PROPERTIES
> INTERFACE_INCLUDE_DIRECTORIES
>  "${_IMPORT_PREFIX}/include/KF5/Akonadi/Contact;
>   ${_IMPORT_PREFIX}/include/KF5;
>   ${_IMPORT_PREFIX}/include/KF5/akonadi/contact;
>   ${_IMPORT_PREFIX}/include/KF5"
>   INTERFACE_LINK_LIBRARIES "KF5::AkonadiCore;KF5::Contacts;Qt5::Widgets"
> )

Hmm, indeed that does look correct.
I wonder why Digikam would fail to compile then:

19:24:09 
/home/jenkins/sources/digikam/kf5-qt5/utilities/kdesupport/akonadi/akonadiiface.cpp:47:44:
fatal error: Akonadi/Contact/ContactSearchJob: No such file or
directory

Any ideas? (I assume Digikam is trying using to use AkonadiContact correctly)

Cheers,
Ben

>
> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
>
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [Kde-pim] Akonadi Contact library: Targets not properly exported

[Ben Cooksley]

On Tue, Mar 29, 2016 at 10:46 PM, Sandro Knauß <skna...@kde.org> wrote:
> Hi,

Hi Sandro,

>
> for me it looks okay. :
> kdepimlibs/akonadi-contac/src/CmakeFile.txt shows:
> ecm_generate_headers (AkonadiContact_CamelCase_HEADERS
> HEADERS
> [...]
> ContactSearchJob
> [...]
> REQUIRED_HEADERS AkonadiContact_HEADERS
> PREFIX Akonadi/Contact
> )
>
>
> install( FILES
> ${AkonadiContact_CamelCase_HEADERS}
> DESTINATION ${KDE_INSTALL_INCLUDEDIR_KF5}/Akonadi/Contact COMPONENT Devel
> )
>
> install( FILES
> ${AkonadiContact_HEADERS}
> ${CMAKE_CURRENT_BINARY_DIR}/akonadi-contact_export.h
> editor/im/improtocols.h
> DESTINATION ${KDE_INSTALL_INCLUDEDIR_KF5}/akonadi/contact COMPONENT Devel
> )
>
> also the build of kdepimlibs shows that it is installed:
> 05:01:45 -- Installing: /home/jenkins/sources/kdepimlibs/stable-kf5-qt5/local-
> inst/srv/jenkins/install/ubuntu/x86_64/g++/stable-kf5-qt5/kde/kdepimlibs/inst/
> usr/include/KF5/Akonadi/Contact/ContactSearchJob

Those are the header generation and installation routines - which do
indeed look.
What is missing in this case is the include path specification for the
KF5::AkonadiContact target which CMake provides.

>
> Regards,
>
> sandro

Cheers,
Ben

>
> Am Dienstag, 29. März 2016, 14:48:38 CEST schrieb Ben Cooksley:
>> Hi PIM developers,
>>
>> It would appear the Akonadi Contact library does not properly export
>> it's targets, or does so in a manner in which valid include paths for
>> Akonadi libraries are not included in this.
>>
>> Could someone please take a look?
>>
>> This causes Digikam to fail to build on the CI system, please see
>> https://build.kde.org/view/FAILED/job/digikam%20master%20kf5-qt5/6/PLATFORM=
>> Linux,compiler=gcc/console
>>
>> Thanks,
>> Ben
>> ___
>> KDE PIM mailing list kde-...@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-pim
>> KDE PIM home page at http://pim.kde.org/
>
>
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Plasma Workspace - Improperly exporting targets

[Ben Cooksley]

On Wed, Mar 30, 2016 at 3:19 AM, Aleix Pol <aleix...@kde.org> wrote:
> On Tue, Mar 29, 2016 at 11:07 AM, Ben Cooksley <bcooks...@kde.org> wrote:
>> On Tue, Mar 29, 2016 at 7:03 PM, Martin Graesslin <mgraess...@kde.org> wrote:
>>> On Tuesday, March 29, 2016 10:13:02 AM CEST Ben Cooksley wrote:
>>>> Hi Plasma Devs,
>>>>
>>>> It would appear Plasma Workspace is improperly exporting it's targets,
>>>> leading to build failures. This particularly affects Apper, which is
>>>> unable to build on the CI system as a result. Please ensure when
>>>> exporting targets / finding libraries that the full path to the
>>>> library is given, not a short name.
>>>>
>>>> Please see
>>>> https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compile
>>>> r=gcc/consoleFull for more details.
>>>
>>> Well it looks like Apper is doing it wrong. It links kworkspace5 instead of
>>> PW::KWorkspace
>>
>> If someone could push a fix to Apper that would be appreciated.
>> (I don't have the necessary environment and would be making it blindly)
>
> Fixed.

Thanks, Apper is now green :)

>
> Aleix

Cheers,
Ben

> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Plasma Workspace - Improperly exporting targets

[Ben Cooksley]

On Tue, Mar 29, 2016 at 7:03 PM, Martin Graesslin <mgraess...@kde.org> wrote:
> On Tuesday, March 29, 2016 10:13:02 AM CEST Ben Cooksley wrote:
>> Hi Plasma Devs,
>>
>> It would appear Plasma Workspace is improperly exporting it's targets,
>> leading to build failures. This particularly affects Apper, which is
>> unable to build on the CI system as a result. Please ensure when
>> exporting targets / finding libraries that the full path to the
>> library is given, not a short name.
>>
>> Please see
>> https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compile
>> r=gcc/consoleFull for more details.
>
> Well it looks like Apper is doing it wrong. It links kworkspace5 instead of
> PW::KWorkspace

If someone could push a fix to Apper that would be appreciated.
(I don't have the necessary environment and would be making it blindly)

>
> Cheers
> Martin

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Akonadi Contact library: Targets not properly exported

[Ben Cooksley]

Hi PIM developers,

It would appear the Akonadi Contact library does not properly export
it's targets, or does so in a manner in which valid include paths for
Akonadi libraries are not included in this.

Could someone please take a look?

This causes Digikam to fail to build on the CI system, please see
https://build.kde.org/view/FAILED/job/digikam%20master%20kf5-qt5/6/PLATFORM=Linux,compiler=gcc/console

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

KHotKeys: Plugin metadata missing?

[Ben Cooksley]

Hi Plasma Devs,

It would seem that KHotkeys now fails to build, due to either:
a) Missing plugin metadata
b) Missing CMake target dependencies between the automoc task and the
task that generates the plugin metadata.

Could someone correct this please?
https://build.kde.org/view/branchGroup%20kf5-qt5/job/khotkeys%20master%20kf5-qt5/2/PLATFORM=Linux,compiler=gcc/console

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Plasma Workspace - Improperly exporting targets

[Ben Cooksley]

On Tue, Mar 29, 2016 at 10:59 AM, Stephen Kelly <steve...@gmail.com> wrote:
> Ben Cooksley wrote:
>
>> Hi Plasma Devs,
>>
>> It would appear Plasma Workspace is improperly exporting it's targets,
>> leading to build failures. This particularly affects Apper, which is
>> unable to build on the CI system as a result. Please ensure when
>> exporting targets / finding libraries that the full path to the
>> library is given, not a short name.
>>
>> Please see
>> https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compiler=gcc/consoleFull
>> for more details.
>
> Hi Ben,

Hi Steve,

>
> Is this a result of some specific recent commit? Or has it been failing list
> this for a while?

Unfortunately it isn't possible to tell - the previous CI system was
wiped when we migrated to the new system.
I suspect it has probably been failing for some time, but can't confirm that.

Sorry I can't provide much more information here.

>
> Thanks,
>
> Steve.

Thanks,
Ben

>
>
> ___
> Kde-buildsystem mailing list
> Kde-buildsystem@kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Plasma Workspace - Improperly exporting targets

[Ben Cooksley]

Hi Plasma Devs,

It would appear Plasma Workspace is improperly exporting it's targets,
leading to build failures. This particularly affects Apper, which is
unable to build on the CI system as a result. Please ensure when
exporting targets / finding libraries that the full path to the
library is given, not a short name.

Please see 
https://build.kde.org/job/apper%20master%20kf5-qt5/3/PLATFORM=Linux,compiler=gcc/consoleFull
for more details.

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

kdepim-runtime: Missing CMake dependency targets

[Ben Cooksley]

Hi,

It seems some internal targets within kdepim-runtime are missing
appropriate dependency target settings.

Please see 
https://build-sandbox.kde.org/job/kdepim-runtime%20master%20kf5-qt5/lastFailedBuild/PLATFORM=Linux,compiler=gcc/console

Could someone please investigate?

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Ben Cooksley]

On Mon, Jun 8, 2015 at 7:13 PM, David Faure fa...@kde.org wrote:
 That wasn't very constructive/positive...

Sorry, i've spent way too much time fighting with the Qt folks on this one.


 On Monday 08 June 2015 15:22:20 Ben Cooksley wrote:
 The Qt developers
 didn't want to provide any infrastructure at all to make developer
 environments (including our CI system) easier.

 The *any* here is too broad. One approach was rejected, there are tons of
 others. E.g. just naming the variables QT_ instead of XDG_ might have been
 less controversial.

Thiago rejected that approach immediately when I suggested it over IRC.
He basically said it was XDG_* or nothing, and won't allow XDG_* to
proceed unless it is given the okay by the previously mentioned
unresponsive Digia employee.

As maintainer of QtCore he holds veto rights in this instance I believe.

 But since everyone was saying, at the same time, that end users don't want env
 vars, I can understand that the Qt developers thought this issue needs more
 thinking, to solve all uses cases, not just KDE CI (which was a too
 restrictive line of argumentation compared to what it really was, developer
 setup, as you say).

 The maintainer(s) of
 the QStandardPaths class never reviewed our patch

 That would be me, and since I don't know how things should work on OSX, I am
 not in a good position to decide. On top of that I come from the KDE world, so
 I can't really force a KDE patch into Qt if it's a bit controversial.

That makes sense.


 , and the module
 maintainer for QtCore wanted the opinion of a Digia employee who was
 extremely unresponsive.

 --
 David Faure, fa...@kde.org, http://www.davidfaure.fr
 Working on KDE Frameworks 5


Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Challenge for real experts: why does cmake on CI not use automoc for a certain file?

[Ben Cooksley]

On Sat, Jun 6, 2015 at 10:07 PM, Alex Merry alex.me...@kde.org wrote:
 On Friday 05 June 2015 00:58:30 Friedrich W. H. Kossebau wrote:
 you are a cmake and KDE buildsystem expert?
 Prove that yourself and improve the world for others ;)

 Or, indeed, work towards becoming such an expert...


 Here is the challenge:

 https://build.kde.org/job/calligra%20frameworks%20kf5-qt5/PLATFORM=Linux,Var
 iation=All,compiler=gcc/28/consoleText

 CMakeFiles/KisAsyncMergerTest.dir/kis_async_merger_test.cpp.o: In function
 `KisAsyncMergerTest::KisAsyncMergerTest()':
 /home/jenkins/builds/calligra/kf5-
 qt5/krita/image/tests/kis_async_merger_test.h:24: undefined reference to
 `vtable for KisAsyncMergerTest'
 CMakeFiles/KisAsyncMergerTest.dir/kis_async_merger_test.cpp.o: In function
 `KisAsyncMergerTest::~KisAsyncMergerTest()':
 /home/jenkins/builds/calligra/kf5-
 qt5/krita/image/tests/kis_async_merger_test.h:24: undefined reference to
 `vtable for KisAsyncMergerTest'
 collect2: error: ld returned 1 exit status
 krita/image/tests/CMakeFiles/KisAsyncMergerTest.dir/build.make:89: recipe
 for target 'krita/image/tests/KisAsyncMergerTest' failed

 Right, you say, smells like automoc not run. And indeed it is not run. So
 far you are an expert.

 But why?
 Why does cmake on CI not want to run automoc on
 kis_async_merger_test.{h,cpp}?

 Locally it works fine for anyone (cmake 3.0.1/3.0.2), noone yet was able to
 reproduce the problem, instead everyone sees:

 So my first question is: what version of cmake is being run on the build
 servers? If it's not 3.0.1 or 3.0.2, then that could explain why you can't
 reproduce it locally.

The CI system is using cmake version 3.1.3 on Ubuntu Vivid (15.04).
Not sure if that makes a difference.


 Alex

Thanks,
Ben


 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Ben Cooksley]

On Sat, Jun 6, 2015 at 9:41 PM, Alex Merry alex.me...@kde.org wrote:
 On Wednesday 27 May 2015 06:56:29 Allen Winter wrote:
 On Tuesday, May 26, 2015 09:12:13 AM Scarlett Clark wrote:
  On Tuesday, May 26, 2015 12:06:22 PM Allen Winter wrote:
   % kdesrc-build kio
   Could not locate file kf5/kdoctools/customization in
   (/Users/allenwinter/Library/Application Support, /Library/Application
   Support) Could not locate file kf5/kdoctools/customization in
   (/Users/allenwinter/Library/Application Support, /Library/Application
   Support) Error: Could not find kdoctools catalogs
  
   kdesrc-build kdoctools succeeded though.
   I recall this was a QStandardPaths thing. but I forgot the trick to
   solving.
  
   help.
 
  -DCMAKE_INSTALL_BUNDLEDIR={instPrefix}/Applications/KF5 -
  DDATA_INSTALL_DIR={instPrefix}/Library/Application Support

 Why can't we put these settings in the top-level buildsystem?

 IIRC, there was some disagreement over the correct approach to take, both on
 OSX and Windows (installing to the operating system's idea of where various
 files should go vs patching Qt to allow for environment variables to put them
 in other places). I think the outcome of that was that KDEers generally
 preferred the patching Qt route, but Qt didn't want to take that upstream.

Just to clarify here: environment variables would never work for final
end user installations, so we need to be able to work with how the OS
likes to work for that.

Developer environments however are different, and was the use case we
were trying to resolve with the patches we sent in. The Qt developers
didn't want to provide any infrastructure at all to make developer
environments (including our CI system) easier. The maintainer(s) of
the QStandardPaths class never reviewed our patch, and the module
maintainer for QtCore wanted the opinion of a Digia employee who was
extremely unresponsive.


 Now, KDEInstallDirs currently sets KDE_INSTALL_BUNDLEDIR (which is the same as
 CMAKE_INSTALL_BUNDLEDIR) to /Applications/KDE, but sets KDE_INSTALL_DATADIR
 (which is the same as DATA_INSTALL_DIR) to ${CMAKE_INSTALL_PREFIX}/share. We
 could adjust those on OSX, but I don't know what would be the most useful
 settings. does $prefix/Applications or $prefix/Library make sense if $prefix
 is not / or $HOME? How do we deal with developers who just want to put
 something locally in their home dir vs proper installations? I don't know a
 whole lot about OSX software installation, so I'm not best placed to make
 these decisions.

 Alex

Regards,
Ben

 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe behavioural change regressions in release branch

[Ben Cooksley]

On Sat, Oct 25, 2014 at 7:14 PM, Stephen Kelly steve...@gmail.com wrote:
 Ben Cooksley wrote:

 On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote:
 Is build.kde.org now using the release branch of cmake.git instead of the
 next branch? When/why did that change?

 This was changed around about
 http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html

 That thread is... unsettling. No participant suggested reporting the issue.
 Four months later bigger waves are made.

Yes.


 KDE and CMake are the same in that both rely on people hitting problems to
 report them.

 This could have been fixed mere days after it hit master.

 Something for KDE to learn from I hope.

If anyone is interested, help would be appreciated to get a Contracts
style build up and running.
In particular, pointers to documentation on how to perform such builds
would be appreciated - we'll need to run make install for parts of
it which doesn't seem to happen in any of the existing examples as far
as I can see.


 Thanks,

 Steve.


Thanks,
Ben


 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe behavioural change regressions in release branch

[Ben Cooksley]

On Mon, Oct 27, 2014 at 6:24 AM, Albert Astals Cid aa...@kde.org wrote:
 Hi guys, what's the status of this?

Hi Albert,

I'm waiting for the fixes for this issue, in particular
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=5f414cefb6524d26329484b296004e3c2d97ec4f
to land in 'release'.

Once that happens i'll rebuild CMake on the CI system and rebuild all
Frameworks to get the system back into working order.


 As far as i can see it's still unresolved since kcoreaddons is installing much
 fewer headers than it used to

 http://build.kde.org/job/kcoreaddons_master_qt5/153/console
   vs
 http://build.kde.org/job/kcoreaddons_master_qt5/152/console

 Do you think it's a valid case to autotest?

I believe tests have now been added to CMake to test for this issue.


 Cheers,
   Albert

Thanks,
Ben


 El Divendres, 24 d'octubre de 2014, a les 19:23:42, Ben Boeckel va escriure:
 On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote:
  On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote:
   Is build.kde.org now using the release branch of cmake.git instead of
   the
   next branch? When/why did that change?
 
  This was changed around about
  http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html
  The motivation behind the change was to get the CI system to have the
  same setup as developers I think, and to avoid regressions in 3.1
  which had been causing some build problems at the time. Those same
  regressions are the ones causing us issues now.
 
  Interestingly, the commit which was identified as causing the issue
  occurred back in March, yet this thread was in June. So perhaps there
  may be other commits interacting here (or that was the time when the
  commit previously identified was merged into the next branch).

 Earlier this year, I was working on lots of performance metrics of CMake
 and this was part of it. There ended up being more than a dozen branches
 resulting from that work (some of them still unmerged). Doing some
 digging shows that this is where the commit finally hit master:

 commit bd20dd6b8a925a421167602027fff9b904fd0822
 Merge: b041fc1 e17a69b
 Author: Brad King brad.k...@kitware.com
 Date:   Thu Jun 12 11:28:44 2014 -0400

 so June looks right.

 --Ben
 ___
 Kde-frameworks-devel mailing list
 kde-frameworks-de...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe behavioural change regressions in release branch

[Ben Cooksley]

On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote:
 Ben Cooksley wrote:

 Hi all,

 It would appear that CMake 3.0 to 3.1 introduces a colossal change in
 behaviour. This change totally breaks all KDE projects which use
 Extra-CMake-Modules, as necessary headers are no longer installed.

 This has become an issue following http://build.kde.org/job/cmake/160/
 which has led to a significant number of our projects failing to build
 from source as can be seen here -
 http://build.kde.org/view/Frameworks/

Hi Steve,


 Is build.kde.org now using the release branch of cmake.git instead of the
 next branch? When/why did that change?

This was changed around about
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html
The motivation behind the change was to get the CI system to have the
same setup as developers I think, and to avoid regressions in 3.1
which had been causing some build problems at the time. Those same
regressions are the ones causing us issues now.

Interestingly, the commit which was identified as causing the issue
occurred back in March, yet this thread was in June. So perhaps there
may be other commits interacting here (or that was the time when the
commit previously identified was merged into the next branch).


 Thanks,

 Steve.

Thanks,
Ben



 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Severe behavioural change regressions in release branch

[Ben Cooksley]

Hi all,

It would appear that CMake 3.0 to 3.1 introduces a colossal change in
behaviour. This change totally breaks all KDE projects which use
Extra-CMake-Modules, as necessary headers are no longer installed.

This has become an issue following http://build.kde.org/job/cmake/160/
which has led to a significant number of our projects failing to build
from source as can be seen here -
http://build.kde.org/view/Frameworks/

Someone needs to investigate this before CMake 3.1.0 goes out the door
and fix it. I've no idea what the policy is in the CMake world, but in
the KDE world this sort of compatibility breakage would be a release
blocker.

Regards,
Ben Cooksley
KDE Sysadmin
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe behavioural change regressions in release branch

[Ben Cooksley]

On Fri, Oct 24, 2014 at 10:05 AM, Ben Cooksley bcooks...@kde.org wrote:
 Hi all,

 It would appear that CMake 3.0 to 3.1 introduces a colossal change in
 behaviour. This change totally breaks all KDE projects which use
 Extra-CMake-Modules, as necessary headers are no longer installed.

 This has become an issue following http://build.kde.org/job/cmake/160/
 which has led to a significant number of our projects failing to build
 from source as can be seen here -
 http://build.kde.org/view/Frameworks/

 Someone needs to investigate this before CMake 3.1.0 goes out the door
 and fix it. I've no idea what the policy is in the CMake world, but in
 the KDE world this sort of compatibility breakage would be a release
 blocker.

And it would seem that the CMake developers prefer to live in their
own closed off little bubble. My post was automatically rejected.
Someone who is subscribed there will have to take this up with them.
I'm extremely displeased.

If they release CMake 3.1.0 with this regression, we should consider
forking CMake as their developers can't be trusted to ensure our code
remains buildable.


 Regards,
 Ben Cooksley
 KDE Sysadmin

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe behavioural change regressions in release branch

[Ben Cooksley]

On Fri, Oct 24, 2014 at 10:41 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
 On 10/23/2014 5:11 PM, Ben Cooksley wrote:

 And it would seem that the CMake developers prefer to live in their
 own closed off little bubble.

Hi Bill,


 Sorry about that.  We just want to avoid spam.  I have forwarded your
 message to the cmake-developers mailing list.  Thanks for the report.

Okay, sounds reasonable enough. Thanks for taking care of that.


 -Bill


Thanks,
Ben


 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe behavioural change regressions in release branch

[Ben Cooksley]

On Fri, Oct 24, 2014 at 10:11 AM, Ben Cooksley bcooks...@kde.org wrote:
 On Fri, Oct 24, 2014 at 10:05 AM, Ben Cooksley bcooks...@kde.org wrote:
 Hi all,

 It would appear that CMake 3.0 to 3.1 introduces a colossal change in
 behaviour. This change totally breaks all KDE projects which use
 Extra-CMake-Modules, as necessary headers are no longer installed.

 This has become an issue following http://build.kde.org/job/cmake/160/
 which has led to a significant number of our projects failing to build
 from source as can be seen here -
 http://build.kde.org/view/Frameworks/

 Someone needs to investigate this before CMake 3.1.0 goes out the door
 and fix it. I've no idea what the policy is in the CMake world, but in
 the KDE world this sort of compatibility breakage would be a release
 blocker.

 And it would seem that the CMake developers prefer to live in their
 own closed off little bubble. My post was automatically rejected.
 Someone who is subscribed there will have to take this up with them.
 I'm extremely displeased.

 If they release CMake 3.1.0 with this regression, we should consider
 forking CMake as their developers can't be trusted to ensure our code
 remains buildable.

Sorry for the above all, got a bit caught up in the heat of the moment.
That shouldn't have come out in the way it did.

Hopefully we have a solution on the way now...



 Regards,
 Ben Cooksley
 KDE Sysadmin

 Regards,
 Ben

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Gwenview CI failure

[Ben Cooksley]

Hi all,

For some time now (since the Baloo functionality merge) Gwenview has
failed to build on the CI system.

See http://build.kde.org/view/FAILED/job/gwenview_master/206/consoleText
 for the build log.

This appears to be due to Baloo using KFileMetaData includes, but not
properly specifying it as a dependency. This shouldn't be a problem if
*Config.cmake files and link targets are used.

Can someone please take a look?

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Build failed in Jenkins: kdelibs_frameworks_qt5 #1806

[Ben Cooksley]

On Mon, Dec 2, 2013 at 1:28 PM, David Faure fa...@kde.org wrote:

 On Sunday 01 December 2013 23:43:02 KDE CI System wrote:
  -- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
  -- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
  -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
  -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
  -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
  -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
  -- Performing Test COMPILER_HAS_DEPRECATED_ATTR
  -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
  Configure step exited with non-zero code, assuming failure to configure
 for
  project kdelibs. Build step 'Execute shell' marked build as failure

 Looks like a bug in cmake_next, leading to infinite recursion and
 therefore a crash.


As a temporary workaround, to keep the CI system functional I have reverted
to the last known good revision of cmake[next].



 jenkins@slave1:/srv/jenkins/workspace/kdelibs_frameworks_qt5/build ls -la
 total 291024
 drwxr-xr-x  4 jenkins users  4096 Dec  1 23:43 .
 drwxr-xr-x 11 jenkins users  4096 Dec  1 23:42 ..
 drwxr-xr-x  4 jenkins users  4096 Dec  1 23:42 CMakeFiles
 -rw---  1 jenkins users 297910272 Dec  1 23:43 core
 -rw-r--r--  1 jenkins users  3187 Dec  1 23:42 CPackConfig.cmake
 -rw-r--r--  1 jenkins users  3607 Dec  1 23:42 CPackSourceConfig.cmake
 drwxr-xr-x  6 jenkins users  4096 Dec  1 23:42 tier1

 jenkins@slave1:/srv/jenkins/workspace/kdelibs_frameworks_qt5/build file
 core
 core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from
 'cmake -DECMATEST_BASEDIR=/home/jenkins/scripts/ecma262
 -DCMAKE_BUILD_TYPE=Debug'


 #44 0x006d487c in cmMakefile::ExecuteCommand(cmListFileFunction
 const, cmExecutionStatus) ()
 #45 0x007fe43d in
 cmMacroHelperCommand::InvokeInitialPass(std::vectorcmListFileArgument,
 std::allocatorcmListFileArgument  const, cmExecutionStatus)
 ()
 #46 0x006d487c in cmMakefile::ExecuteCommand(cmListFileFunction
 const, cmExecutionStatus) ()
 #47 0x007fe43d in
 cmMacroHelperCommand::InvokeInitialPass(std::vectorcmListFileArgument,
 std::allocatorcmListFileArgument  const, cmExecutionStatus)
 ()
 #48 0x006d487c in cmMakefile::ExecuteCommand(cmListFileFunction
 const, cmExecutionStatus) ()
 #49 0x007fe43d in
 cmMacroHelperCommand::InvokeInitialPass(std::vectorcmListFileArgument,
 std::allocatorcmListFileArgument  const, cmExecutionStatus)
 ()
 #50 0x006d487c in cmMakefile::ExecuteCommand(cmListFileFunction
 const, cmExecutionStatus) ()
 #51 0x007fe43d in
 cmMacroHelperCommand::InvokeInitialPass(std::vectorcmListFileArgument,
 std::allocatorcmListFileArgument  const, cmExecutionStatus)
 ()
 #52 0x006d487c in cmMakefile::ExecuteCommand(cmListFileFunction
 const, cmExecutionStatus) ()
 [...]


 --
 David Faure, fa...@kde.org, http://www.davidfaure.fr
 Working on KDE, in particular KDE Frameworks 5

 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem


Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Regression in CMake breaking builds

[Ben Cooksley]

Hi all,

It appears that a recent update to CMake on build.kde.org has broken a
number of KDE projects, resulting in them now failing to build.

An example can be found here:
http://build.kde.org/view/FAILED/job/kdevplatform_master/560/consoleText

The following projects appear to be affected at this time:
- Calligra
- KDevPlatform
- Amarok

CMake folks, can you please take a look?
The CMake build is http://build.kde.org/view/All/job/cmake/78/

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 110843: Ensure we actually have Qwt 5 by looking for a header present only in Qwt 5

[Ben Cooksley]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110843/
---

Review request for Build System and Plasma.


Description
---

This fixes the build failures on Jenkins by looking for a header specific to 
Qwt 5, instead of a general Qwt header.


Diffs
-

  applets/kdeobservatory/cmake/modules/FindQwt.cmake 7045388 

Diff: http://git.reviewboard.kde.org/r/110843/diff/


Testing
---


Thanks,

Ben Cooksley

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE Workspace broken due to upstream CMake changes

[Ben Cooksley]

On Fri, May 31, 2013 at 12:24 AM, Stephen Kelly steve...@gmail.com wrote:
 Stephen Kelly wrote:

 Ben Cooksley wrote:

 Hi Alex,

 Can someone more familiar with the CMake community please inform them
 of this regression?



 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46742/focus=46776

Hi Stephen,


 I have pushed a fix to next. Please update and try again.

Much appreciated. The build of kde-workspace is now successful again.
Thanks for taking care of that.


 Thanks,

 Steve.



Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE Workspace broken due to upstream CMake changes

[Ben Cooksley]

Hi Alex,

Can someone more familiar with the CMake community please inform them
of this regression?
It is breaking the KDE Continuous Integration system - i'd appreciate
being informed once the fix has landed in their Git repository, so we
can deploy it.

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

KDE Workspace broken due to upstream CMake changes

[Ben Cooksley]

Hi all,

It seems that a recent upstream change in CMake has now broken the
build of KDE Workspace. Can someone please fix or prod CMake upstream
into revising their policies?

The lack of warning here concerning the change is a little irritating.

-- Looking for XkbLockModifiers in X11
CMake Error at CMakeLists.txt:10 (ADD_EXECUTABLE):
  Target cmTryCompileExec70252 links to item /usr/lib64/libXpm.so 
  which has leading or trailing whitespace.  This is now an error according
  to policy CMP0004.


CMake Error: Internal CMake error, TryCompile generation of cmake failed
-- Looking for XkbLockModifiers in X11 - not found

Regards,
Ben Cooksley
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE Workspace broken due to upstream CMake changes

[Ben Cooksley]

On Tue, May 28, 2013 at 7:37 AM, Alexander Neundorf neund...@kde.org wrote:
 On Monday 27 May 2013, Rolf Eike Beer wrote:
 Am 27.05.2013 09:13, schrieb Ben Cooksley:
  Hi all,
 
  It seems that a recent upstream change in CMake has now broken the
  build of KDE Workspace. Can someone please fix or prod CMake upstream
  into revising their policies?
 
  The lack of warning here concerning the change is a little irritating.
 
  -- Looking for XkbLockModifiers in X11
 
  CMake Error at CMakeLists.txt:10 (ADD_EXECUTABLE):
Target cmTryCompileExec70252 links to item
 
  /usr/lib64/libXpm.so 
 
which has leading or trailing whitespace.  This is now an error
 
  according
 
to policy CMP0004.
 
  CMake Error: Internal CMake error, TryCompile generation of cmake
  failed
  -- Looking for XkbLockModifiers in X11 - not found

 That's what the policies are for at all ;)

 hmm, not really.
 CMP0004 is not new. It was working with cmake 2.8.10, so it should, well must,
 work also with 2.8.11.

Does this mean we have found a regression in CMake?
Or is the policy being enforced more strictly now?

(ie. should CMake be fixed, or do we need to be fixed)


 Alex

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE Workspace broken due to upstream CMake changes

[Ben Cooksley]

On Tue, May 28, 2013 at 12:51 AM, Rolf Eike Beer
k...@opensource.sf-tec.de wrote:
 Am 27.05.2013 09:13, schrieb Ben Cooksley:

 Hi all,

 It seems that a recent upstream change in CMake has now broken the
 build of KDE Workspace. Can someone please fix or prod CMake upstream
 into revising their policies?

 The lack of warning here concerning the change is a little irritating.

 -- Looking for XkbLockModifiers in X11
 CMake Error at CMakeLists.txt:10 (ADD_EXECUTABLE):
   Target cmTryCompileExec70252 links to item /usr/lib64/libXpm.so 
   which has leading or trailing whitespace.  This is now an error
 according
   to policy CMP0004.


 CMake Error: Internal CMake error, TryCompile generation of cmake failed
 -- Looking for XkbLockModifiers in X11 - not found


 That's what the policies are for at all ;)

 cmake --help-policy CMP0004

 So, fix whatever is causing this, and in the meantime use:

I'm not sure that we are responsible for FindX11 - which is what I
guess is triggering this (based on preceding and following messages
from CMake)


 cmake_policy(SET CMP0004 OLD)

 Eike

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: qt4 vs qt5 build for dependencies

[Ben Cooksley]

On Fri, Apr 5, 2013 at 10:27 PM, David Faure faure+bluesyst...@kde.org wrote:
 When I ported attica, soprano, libdbusmenu-qt and other such kdesupport-
 level dependencies to Qt5, I used

 find_package(Qt5Core QUIET)
 if (Qt5Core_FOUND)
   message(STATUS Building with Qt5 support)
   ...
 else()
   find_package(Qt4 REQUIRED)
 endif()

 i.e. use Qt5 if it's in the user's environment (CMAKE_PREFIX_PATH) otherwise
 look for Qt4.
 I thought this was perfect, it made things work out of the box without any
 manual intervention, for both types of users.
 And it didn't require a separate branch for the qt5 support (we only have this
 in a few modules which started to use qt5 stuff, but for for the majority of
 modules, there's no active development, so branching is not wanted).

 Now here's the problem: nowadays distros are starting to have Qt5 in /usr,
 i.e. it's being found automatically. Which makes it impossible to build this
 code for Qt4.

 So I'm afraid I have to drop the idea of automatic detection, and let people
 choose explicitely. My current idea would be to reintroduce -DQT5_BUILD=true
 (like we had in kdelibs at some point; but this discussion isn't about kdelibs
 obviously), i.e. default to the Qt4 build, since that's what KDE SC releases
 are still about.

 Later on, when we're about to release KF5, we want to turn this around, i.e.
 make it easy to build things for Qt5, and if we still need qt4 support at that
 point, adding a -DQT4_BUILD=true (and dropping the QT5_BUILD variable,
 obviously).

 Opinions? Better ideas?

Assuming the user had given no guidance, would it be possible to
attempt a fallback to Qt 5 if it was not possible to find Qt 4?
Obviously if the user gives guidance that should override.

I'm otherwise neutral - just let me know beforehand please so I can
adjust the CI system to pass the new argument(s).

Regards,
Ben


 --
 David Faure, fa...@kde.org, http://www.davidfaure.fr
 Sponsored by BlueSystems and KDAB to work on KDE Frameworks

 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Problems with ECM / FindKDE4Internal and plasma-framework

[Ben Cooksley]

On Fri, Feb 8, 2013 at 6:38 AM, Alexander Neundorf neund...@kde.org wrote:
 On Thursday 07 February 2013, Ben Cooksley wrote:
 On Thu, Feb 7, 2013 at 7:34 AM, Alexander Neundorf neund...@kde.org wrote:
  On Tuesday 05 February 2013, Alexander Neundorf wrote:
  On Monday 04 February 2013, Ben Cooksley wrote:
   Hi all,
  
   Currently the KDE CI system is unable to build the newly created
   'plasma-framework' repository. Through some debugging I have
   determined that although all appropriate environment variables are set
   correctly (to the best of my knowledge) it seems that CMake is simply
   blind, or something (likely in ECM) is making it blind.

 Hi Alex,

  how is plasma-framework trying to find the installed kdelibs from the
  frameworks branch ?
  AFAIK this is not possible.
  If it does
  find_package(KDE4)
  this does not work.
  FindKDE4.cmake coming with cmake searches for kde4-config, but the
  frameworks branch installs kde5-config, so no chance of being found.
  Are they doing something else ?

 Please see
 https://projects.kde.org/projects/playground/libs/plasma-framework/reposit
 ory/revisions/master/entry/CMakeLists.txt

 It appears they are running
find_package(KDE4Internal REQUIRED)

 From all indications, this should work, as kdelibs frameworks is
 installing a FindKDE4Internal.cmake file.

 Wow, what a mess ;-)
 Don't know where to start.

 FindKDE4Internal.cmake is a find-module, and cmake does not search those, it
 expects them to be either in its own share/cmake/Modules/ directory or in
 CMAKE_MODULE_PATH.
 So it can't be found.
 Probably you can run cmake -
 DCMAKE_MODULE_PATH=/where/kf5/is/share/cmake/modules and it seems to work
 when.

I see. From my testing, it also seems that CMake does seem to care if
a environment variable CMAKE_MODULE_PATH is set.
Is this correct?

If so, I wonder why it works for everything else but Frameworks stuff.
If Extra-CMake-Modules is blocking an environment variable from
working i'd appreciate it if it didn't, because environment variables
are *far* more convenient for build.kde.org compared to CMake
arguments.


 Additionally, they search for find_path(KDE_MODULES_DIR NAMES KDE4Macros.cmake
 ...)
 which is included later on by FindKDE4Internal.cmake anyway.


 Do they really need Win CE support ?

 Then all the options are set manually...

 OTOH, AFAIK currently at least I am not aware of what the official way of
 using the frameworks branch of kdelibs is.

 Do we have an official way ?

 Alex

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Problems with ECM / FindKDE4Internal and plasma-framework

[Ben Cooksley]

On Fri, Feb 8, 2013 at 11:16 AM, Alexander Neundorf neund...@kde.org wrote:
 On Thursday 07 February 2013, Ben Cooksley wrote:
 On Fri, Feb 8, 2013 at 6:38 AM, Alexander Neundorf neund...@kde.org wrote:
  On Thursday 07 February 2013, Ben Cooksley wrote:
  On Thu, Feb 7, 2013 at 7:34 AM, Alexander Neundorf neund...@kde.org
 wrote:
   On Tuesday 05 February 2013, Alexander Neundorf wrote:
   On Monday 04 February 2013, Ben Cooksley wrote:
Hi all,
   
Currently the KDE CI system is unable to build the newly created
'plasma-framework' repository. Through some debugging I have
determined that although all appropriate environment variables are
set correctly (to the best of my knowledge) it seems that CMake is
simply blind, or something (likely in ECM) is making it blind.
 
  Hi Alex,
 
   how is plasma-framework trying to find the installed kdelibs from the
   frameworks branch ?
   AFAIK this is not possible.
   If it does
   find_package(KDE4)
   this does not work.
   FindKDE4.cmake coming with cmake searches for kde4-config, but the
   frameworks branch installs kde5-config, so no chance of being found.
   Are they doing something else ?
 
  Please see
  https://projects.kde.org/projects/playground/libs/plasma-framework/repos
  it ory/revisions/master/entry/CMakeLists.txt
 
  It appears they are running
 
 find_package(KDE4Internal REQUIRED)
 
  From all indications, this should work, as kdelibs frameworks is
  installing a FindKDE4Internal.cmake file.
 
  Wow, what a mess ;-)
  Don't know where to start.
 
  FindKDE4Internal.cmake is a find-module, and cmake does not search
  those, it expects them to be either in its own share/cmake/Modules/
  directory or in CMAKE_MODULE_PATH.
  So it can't be found.
  Probably you can run cmake -
  DCMAKE_MODULE_PATH=/where/kf5/is/share/cmake/modules and it seems to work
  when.

 I see. From my testing, it also seems that CMake does seem to care if
 a environment variable CMAKE_MODULE_PATH is set.
 Is this correct?

 If so, I wonder why it works for everything else but Frameworks stuff.
 If Extra-CMake-Modules is blocking an environment variable from
 working i'd appreciate it if it didn't, because environment variables
 are *far* more convenient for build.kde.org compared to CMake
 arguments.

 No, e-c-m does not block anything from working.
 Find-modules should not be searched, it's their task to search, not to be
 found.

I see.


 I am working on the plasma buildsystem right now.

Thanks for fixing the Plasma Framework build system Alex, much appreciated.
The build now passes the CMake stage without a hitch on build.kde.org.

http://build.kde.org/job/plasma-framework_master_qt5/53/consoleText


 Alex

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Problems with ECM / FindKDE4Internal and plasma-framework

[Ben Cooksley]

On Thu, Feb 7, 2013 at 7:34 AM, Alexander Neundorf neund...@kde.org wrote:
 On Tuesday 05 February 2013, Alexander Neundorf wrote:
 On Monday 04 February 2013, Ben Cooksley wrote:
  Hi all,
 
  Currently the KDE CI system is unable to build the newly created
  'plasma-framework' repository. Through some debugging I have
  determined that although all appropriate environment variables are set
  correctly (to the best of my knowledge) it seems that CMake is simply
  blind, or something (likely in ECM) is making it blind.

Hi Alex,


 how is plasma-framework trying to find the installed kdelibs from the
 frameworks branch ?
 AFAIK this is not possible.
 If it does
 find_package(KDE4)
 this does not work.
 FindKDE4.cmake coming with cmake searches for kde4-config, but the frameworks
 branch installs kde5-config, so no chance of being found.
 Are they doing something else ?

Please see 
https://projects.kde.org/projects/playground/libs/plasma-framework/repository/revisions/master/entry/CMakeLists.txt

It appears they are running
   find_package(KDE4Internal REQUIRED)

From all indications, this should work, as kdelibs frameworks is
installing a FindKDE4Internal.cmake file.


 Alex

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Problems with ECM / FindKDE4Internal and plasma-framework

[Ben Cooksley]

Hi all,

Currently the KDE CI system is unable to build the newly created
'plasma-framework' repository. Through some debugging I have
determined that although all appropriate environment variables are set
correctly (to the best of my knowledge) it seems that CMake is simply
blind, or something (likely in ECM) is making it blind.

The problem in this case is that FindKDE4Internal.cmake is not being
found. CMAKE_PREFIX_PATH contains the appropriate location (
/srv/jenkins/install/linux/x64_64/g++/qt5/kde/kdelibs/frameworks ) and
the file exists at
/srv/jenkins/install/linux/x64_64/g++/qt5/kde/kdelibs/frameworks/share/cmake/modules/FindKDE4Internal.cmake

Is there any explanation for it not being found?

There also seems to be an extremely confusing variety of locations
where Find* scripts get installed (virtually all of kde4 installs in
share/apps/cmake while frameworks disregards this - copying the
share/cmake folder to share/apps/cmake had no effect however), while
*Config.cmake files seem relatively standardised on
lib/cmake/projectname. It would be great if this was clarified.

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[kdelibs/KDE/4.10] cmake/modules: Ensure that the pkgconfig material is kept far away from the proper CMake logic.

[Ben Cooksley]

Git commit 0f09cc362819d7818f7ac95ab6a4b55912390011 by Ben Cooksley.
Committed on 06/01/2013 at 08:14.
Pushed by bcooksley into branch 'KDE/4.10'.

Ensure that the pkgconfig material is kept far away from the proper CMake logic.
This fixes build failures for all projects which use kipi on build.kde.org
CCMAIL: kde-buildsystem@kde.org
CCMAIL: caulier.gil...@gmail.com
CCMAIL: dodonvic...@gmail.com

M  +4-4cmake/modules/FindKipi.cmake

http://commits.kde.org/kdelibs/0f09cc362819d7818f7ac95ab6a4b55912390011

diff --git a/cmake/modules/FindKipi.cmake b/cmake/modules/FindKipi.cmake
index 5024450..d9bd8eb 100644
--- a/cmake/modules/FindKipi.cmake
+++ b/cmake/modules/FindKipi.cmake
@@ -78,13 +78,13 @@ ELSE(KIPI_INCLUDE_DIR AND KIPI_LIBRARIES AND 
KIPI_DEFINITIONS AND KIPI_VERSION A
   ENDIF(NOT Kipi_FIND_QUIETLY)
 
   INCLUDE(FindPkgConfig)
-  PKG_CHECK_MODULES(KIPI libkipi=${Kipi_FIND_VERSION})
+  PKG_CHECK_MODULES(PC_KIPI libkipi=${Kipi_FIND_VERSION})
 ENDIF(NOT WIN32)
 
-FIND_LIBRARY(KIPI_LIBRARIES NAMES libkipi PATHS ${KIPI_LIBRARY_DIRS} 
${LIB_INSTALL_DIR} ${KDE4_LIB_DIR})
-FIND_PATH(KIPI_INCLUDE_DIR NAMES libkipi/version.h PATHS 
${KIPI_INCLUDE_DIRS} ${INCLUDE_INSTALL_DIR} ${KDE4_INCLUDE_DIR})
+FIND_LIBRARY(KIPI_LIBRARIES NAMES kipi HINTS ${PC_KIPI_LIBRARY_DIRS} 
${LIB_INSTALL_DIR} ${KDE4_LIB_DIR})
+FIND_PATH(KIPI_INCLUDE_DIR NAMES libkipi/version.h HINTS 
${PC_KIPI_INCLUDE_DIRS} ${INCLUDE_INSTALL_DIR} ${KDE4_INCLUDE_DIR})
 SET(KIPI_VERSION_H_FILENAME ${KIPI_INCLUDE_DIR}/libkipi/version.h)
-SET(KIPI_DEFINITIONS ${KIPI_CFLAGS} CACHE STRING Kipi defintions)
+SET(KIPI_DEFINITIONS ${PC_KIPI_CFLAGS} CACHE STRING Kipi defintions)
 
 INCLUDE(FindPackageHandleStandardArgs)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(KIPI DEFAULT_MSG KIPI_LIBRARIES 
KIPI_INCLUDE_DIR)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [kdepimlibs] /: Interim hack to make everything which depends on kdepimlibs build again.

[Ben Cooksley]

On Thu, Dec 20, 2012 at 9:02 PM, Andreas Pakulat ap...@gmx.de wrote:
 Hi,

Hi,


 On Thu, Dec 20, 2012 at 1:11 AM, Ben Cooksley bcooks...@kde.org wrote:
 Git commit f9ea1c7b4fb351a4da16b386c23f15d6c109728a by Ben Cooksley.
 Committed on 20/12/2012 at 01:11.
 Pushed by bcooksley into branch 'master'.

 Interim hack to make everything which depends on kdepimlibs build again.
 A proper solution is needed from the CMake folks, but I don't see consensus 
 on that.

 FWIW, I think the change you comitted is almost the right fix, you
 forgot a REQUIRED there to ensure that finding kdepimlibs fails if

The ommision of REQUIRED was intentional as kdepimlibs itself does not
require Nepomuk Core.

 nepomuk is not found. If kdepimlibs libraries expose Nepomuk API in
 their own public API then its a dependency of kdepimlibs, this is
 expressed by having nepomuk in the link-interface of the kdepimlibs

Right. I guess the correct fix in this case is an if() block which
checks if Nepomuk had previously been found (and if so - adds the line
in with REQUIRED) and otherwise skips it.

I'll take a look into that.

 libraries. Dependencies have to be searched and found before setting
 up ones own targets and their link-interfaces, so doing that in the
 config file is just fine.

 Andreas

Regards,
Ben


 CCMAIL: kde-buildsystem@kde.org
 CCMAIL: kde-...@kde.org

 M  +2-0KdepimLibsConfig.cmake.in

 http://commits.kde.org/kdepimlibs/f9ea1c7b4fb351a4da16b386c23f15d6c109728a

 diff --git a/KdepimLibsConfig.cmake.in b/KdepimLibsConfig.cmake.in
 index e4c3ee1..41dc802 100644
 --- a/KdepimLibsConfig.cmake.in
 +++ b/KdepimLibsConfig.cmake.in
 @@ -1,5 +1,7 @@
  # KdepimLibs.cmake is generated by CMake from kdepimlibs/KdepimLibs.cmake.in

 +find_package(NepomukCore)
 +
  # set the kdepimlibs version number
  set(KDEPIMLIBS_VERSION_MAJOR @KDEPIMLIBS_VERSION_MAJOR@)
  set(KDEPIMLIBS_VERSION_MINOR @KDEPIMLIBS_VERSION_MINOR@)
 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[kdepimlibs] /: Interim hack to make everything which depends on kdepimlibs build again.

[Ben Cooksley]

Git commit f9ea1c7b4fb351a4da16b386c23f15d6c109728a by Ben Cooksley.
Committed on 20/12/2012 at 01:11.
Pushed by bcooksley into branch 'master'.

Interim hack to make everything which depends on kdepimlibs build again.
A proper solution is needed from the CMake folks, but I don't see consensus on 
that.
CCMAIL: kde-buildsystem@kde.org
CCMAIL: kde-...@kde.org

M  +2-0KdepimLibsConfig.cmake.in

http://commits.kde.org/kdepimlibs/f9ea1c7b4fb351a4da16b386c23f15d6c109728a

diff --git a/KdepimLibsConfig.cmake.in b/KdepimLibsConfig.cmake.in
index e4c3ee1..41dc802 100644
--- a/KdepimLibsConfig.cmake.in
+++ b/KdepimLibsConfig.cmake.in
@@ -1,5 +1,7 @@
 # KdepimLibs.cmake is generated by CMake from kdepimlibs/KdepimLibs.cmake.in
 
+find_package(NepomukCore)
+
 # set the kdepimlibs version number
 set(KDEPIMLIBS_VERSION_MAJOR @KDEPIMLIBS_VERSION_MAJOR@)
 set(KDEPIMLIBS_VERSION_MINOR @KDEPIMLIBS_VERSION_MINOR@)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

kdepimlibs dependency on nepomuk-core breaks build for Calligra and kdeplasma-addons

[Ben Cooksley]

Hi all,

Currently build.kde.org is unable to successfully complete builds of
kdeplasma-addons and Calligra due to recent changes in kdepimlibs.
These changes are a port from Nepomuk (part of kdelibs) to NepomukCore
(a seperate repository).

As kdepimlibs uses the *Config.cmake method of exporting it's
location, this means that the proper location of the library is not
set correctly.
The nepomukcore library will only be found if all projects which
depend on kdepimlibs include the following:
find_package(NepomukCore)

Last time a problem such as this occurred it involved KDevPlatform and
Grantlee - and the fix in that case was to ensure the
KDevPlatformConfig.cmake file included the above find_package line
itself. Can someone please make this adjustment, or propose a better
way of fixing this?

As a further note - you probably won't be able to reproduce this on
your local systems, as the location NepomukCore is installed to is
probably already in the compiler search path.

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: kdepimlibs dependency on nepomuk-core breaks build for Calligra and kdeplasma-addons

[Ben Cooksley]

On Tue, Dec 18, 2012 at 8:14 AM, Alexander Neundorf neund...@kde.org wrote:
 On Monday 17 December 2012, Ben Cooksley wrote:
 Hi all,

 Currently build.kde.org is unable to successfully complete builds of
 kdeplasma-addons and Calligra due to recent changes in kdepimlibs.
 These changes are a port from Nepomuk (part of kdelibs) to NepomukCore
 (a seperate repository).

 As kdepimlibs uses the *Config.cmake method of exporting it's
 location, this means that the proper location of the library is not
 set correctly.

 Of which library ? nepomukcore ?

Yes.

 How is the dependency to nepomukCore recorded in the exported targets file ?

  IMPORTED_LINK_INTERFACE_LIBRARIES_RELWITHDEBINFO
KDEPIMLibs__akonadi-kde;KDEPIMLibs__kabc;KDEPIMLibs__kcalcore;KDEPIMLibs__kmime;KDEPIMLibs__kpimutils;KDE4__kdeui;KDE4__kio;nepomukcore;/srv

 Using the path to the nepomukCore library, or by depending on a target
 nepomukCore ?

As a target - named nepomukcore.


 In the first case, I'm not sure where the breakage is.

 In the second case, kdepimlibsConfig.cmake needs to search nepomukCore first,
 so the targets exist.

 I don't have a recent build of kdepimlibs around, can you attach the installed
 kdepimlibsConfig.cmake file ?

Please find it attached.


 Alex

Thanks,
Ben


KdepimLibsConfig.cmake
Description: Binary data
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Another CMake regression?

[Ben Cooksley]

Hi all,

It seems that following a recent CMake build from latest sources that
the configure time for Calligra has severely regressed.
It now takes in excess of 1 hour to complete the configure process,
which is disrupting the operation of build.kde.org.

Timestamped output:
14:45:29 -- cstester
14:45:29 -- 
--
15:54:52 -- Configuring done

Based on the build times recorded by Jenkins I have determined that
one of the commits listed here
http://build.kde.org/job/cmake/27/changes is at fault.
Does anyone here know which of those commits could possibly be the
ones at fault?

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

KDevelop and Grantlee

[Ben Cooksley]

Hi all,

Currently build.kde.org is having some issues when building all
KDevelop related projects (master branch) after kdevplatform. The
build for various elements in them always fails with an error message
indicating it is unable to find -lgrantlee_core.

Is there something which should be done in KDevPlatform to ensure that
the appropriate grantlee target instead of the library definition
itself is exported so this works properly?

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Changing compiler options

[Ben Cooksley]

Hi all,

Recently build.kde.org ran into some problems with building libkdcraw,
due to CMake using the -std=iso9899:1990 option with GCC.
It seems that this appears to be incompatible with LCMS' use of inline
functions.

The build log can be viewed at
http://build.kde.org/view/FAILED/job/libkdcraw_master/38/console
Changing it out for -std=c99 seems to fix this however - how would one
do this with CMake?

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe test regression in Kate?

[Ben Cooksley]

Hi all,

I will be reverting commit cd8a8d6d3914ce8a72f252b054073193b97dd0a7 in
kate in 24 hours unless a fix is provided. The issue it introduces,
especially with php files is particularly disruptive to user workflow.
(I don't understand exactly how a broken Javascript syntax file can
affect PHP though...)

On my local system, reverting this commit allows highlighting of php
files to function once more, and also permits make test to complete
without intervention. This will also restore normal behaviour of tests
on build.kde.org when performing Kate builds.

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe test regression in Kate?

[Ben Cooksley]

On Fri, Sep 28, 2012 at 7:35 AM, Eddy B. edy.b...@gmail.com wrote:
 Hi all,

Hi Eddy,

 I'm sorry I didn't reply to this sooner, I didn't recognize that commit hash
 as being related to my patch - https://git.reviewboard.kde.org/r/106540/
 I just tested this, and it seems a missing closing brace or a missing
 double-colon in a conditional expression cause the Javascript rules to never
 exit to its main context (which is fine you're highlighting just JS, but
 break HTML's /script).
 About PHP, I thought javascript-php.xml was used there, which I haven't
 touched.

 As an explanation for why that happens: to properly detect if identifier:
 should be highlighted normally (which only makes sense in conditional
 expressions) instead of an object label, a context has to be entered for the
 conditional expression.
 However, you can have a?{b:c}:d, in which case b: should be highlighted
 as an object label. That means you also need to enter a context for the
 object literal - in my a?{b:c}:d example, that would be
 Normal-ConditionalExpr-Object.
 The context stacking can continue, and any missing double-colons (to exit
 ConditionalExpr) or closing braces (to exit Object), will leave extra
 contexts at the end of the JS code, disabling HTML's check for /script.

 I have to point out that while it can be annoying, it shouldn't happen
 unless you have a syntax error in your JS.
 And I don't see a better way to choose how to highlight identifier: - I
 hope you do, otherwise it will be hard to fix this problem nicely.

Unfortunately in this case, the php files I am opening (to test this
with) are extremely basic, with only a couple of lines of php code.
There is certainly nothing that looks like a html or javascript tag.

The error it causes seems to be related to the filename(s) of other
highlighting files, as it gives a Cannot open message box first,
followed by a notice that highlighting is being disabled.


 Thanks, Eddy.

Regards,
Ben


 2012/9/27 Dominik Haumann dhaum...@kde.org

 Hi Ben,

 sorry for not answering immediately.

 On Thursday, 27. September 2012 17:28:48 Ben Cooksley wrote:
  Hi all,
 
  I will be reverting commit cd8a8d6d3914ce8a72f252b054073193b97dd0a7 in
  kate in 24 hours unless a fix is provided. The issue it introduces,
  especially with php files is particularly disruptive to user workflow.
  (I don't understand exactly how a broken Javascript syntax file can
  affect PHP though...)
 
  On my local system, reverting this commit allows highlighting of php
  files to function once more, and also permits make test to complete
  without intervention. This will also restore normal behaviour of tests
  on build.kde.org when performing Kate builds.
 
  Regards,
  Ben

 I quickly ran this one unit test and it worked for me, but I haven't
 investigated in more depth. The highlightings are included in other
 languages
 as well (e.g. from PHP you can get into JavaScript in the same file).

 Please revert, I'll look into this later then.

 Thanks,
 Dominik
 ___
 KWrite-Devel mailing list
 kwrite-de...@kde.org
 https://mail.kde.org/mailman/listinfo/kwrite-devel


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Fwd: Severe test regression in Kate?

[Ben Cooksley]

Forwarding to kde-buildsystem, got no response from kwrite-devel...

-- Forwarded Message --
Hi all,

It seems that following commit
cd8a8d6d3914ce8a72f252b054073193b97dd0a7, test #22
(kate-bug294241_test) has severely regressed. Further, it completely
blocks build.kde.org when it executes (as it somehow manages to
override the CTest limitation of 60 seconds which is applied, and run
indefinitely).

Could someone please investigate that?
If you cannot reproduce this, it would seem we have found yet another
regression in the latest CMake code (which broke the builds of
kdelibs/kde-workspace).

(Please CC me on replies, i'm not subscribed).

Thanks,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request: Fix Kalzium build and cleanup CMake warnings during Kalzium configuration by CMake

[Ben Cooksley]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103209/
---

Review request for Build System and KDE Edu.


Description
---

Currently I cannot build Kalzium, due to the following error message:
gmake[2]: *** No rule to make target `/usr/lib64/libQtOpenGL.so', needed by 
`lib/libcompoundviewer.so.4.7.0'.  Stop.

Combined with some warning output when CMake is run on Kalzium, I determined 
that the dynamic location of libraries, as is currently done for Avogadro is 
problematic.

The patch changes this behaviour so that the path to Avogadro is supplied 
explicitly.
It also fixes a linking issue with my system, where Kalzium refuses to link to 
QtOpenGL as it is not explicitly defined as a dependency.


Diffs
-

  KalziumConfigureChecks.cmake cef3d45 
  compoundviewer/CMakeLists.txt b2b7e6c 
  src/CMakeLists.txt 47ebbd1 

Diff: http://git.reviewboard.kde.org/r/103209/diff/diff


Testing
---

Now compiles.


Thanks,

Ben Cooksley

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Phonon's failure to detect Pulseaudio

[Ben Cooksley]

Hi all,

Currently my system (which has Pulseaudio enabled - version 0.9.21)
with current Phonon master is NOT able to find Pulseaudio. As I need
Pulseaudio in order to use my Bluetooth headset, it is highly
irritating for this to have occurred. Tracing back, I found that this
breakage occurred some time after commit
c7176c2386d160717422315e4cff4c92fa044bbc. Unfortunately I suck with
CMake - and cannot fix it.

This unintended breakage (which I hadn't initially thought to check
for - as it previously detected it - I didn't expect it to break) is
the root cause of both the stutters I experience with Phonon VLC, and
the crashes I recieved with Phonon GStreamer. Phonon Xine handled the
lack of native Pulseaudio support fine. Fortunately the actual ABI of
the source hasn't changed - so I can use my existing backends as they
are - I cannot recompile them due to incompatible changes in the CMake
build system. Now that Phonon itself supports Pulseaudio again - all
three work fine again.

Can someone (with more cmake foo that I) please fix the Pulseaudio
finder to find it accurately?

Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)

[Ben Cooksley]

2011/5/22 Dirk Mueller muel...@kde.org:
 On Saturday 21 May 2011, Eric Hameleers wrote:

 The turn of events with KDE 4.7.x is most unfortunate. I noticed an
 explosion of source tarballs.

 Yes, I started to resemble the git layout in the tarballs, given that I had a
 pain in the ass of work to do with reverting the git splitting for the 4.6
 branch releases. I'll attach them for reference, but those scripts are ugly.
 I'm not aware of a better solution though, unless we use git submodules or
 maintain those scripts in the SVN.

The script used by LXR and the EBN may be of help here in reassembling
the directory tree layout. All you'd have to do then is throw in some
minimal CMake glue to add the modules in the right order. No idea how
much they'd like building like this however. They may try to find()
various items (like edu apps try to find libkdeedu) which might cause
that approach to fail.


 Dirk, are instructions available on how
 to re-assemble sources back to the original set? Or else, are
 instructions available on how to compile the bigger all-comprising
 packages where the separated applications and libraries are included
 again, like was the case all the time up to 4.7?

 I don't have those available at the moment. I used scripts to reassemble them
 to original tarballs, but I haven't properly pushed this into KDE git back
 yet.

 Can I get the opinion of the other distro packagers as well please? Personally
 I was much more happy with the previous module-based layout, though I can cope
 reasonable with the current situation as well. Any other opinon?

 Eric, thanks for sharing your thoughts. I hope we can find a solution that
 suits your needs as well. If all else fails, I'm willing to give maintaining
 those reassembling-scripts a try, but it is an extra effort, given that the
 tarballs are much different from how developers build it, so regressions in 
 the
 build system are likely.

 Greetings,
 Dirk

 ___
 Kde-packager mailing list
 kde-packa...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-packager



Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDEUtils build broken for extended period of time

[Ben Cooksley]

On Mon, Jul 12, 2010 at 6:52 PM, Michael Zanetti
michael_zane...@gmx.net wrote:
 Hi Ben,

 On Sunday 11 July 2010 13:30:11 Ben Cooksley wrote:
 Is there any reason why it has not been possible to build kdeutils for
 some time? ( couple of days at least ). Going back to a previously
 working KDEUtils revision isn't sufficient to fix it either, so I
 suspect it is caused by a change in another module, which concurs with
 the following strange CMake output ( from a fresh build tree if you're
 wondering, and I have no changes on KDELibs or KDEUtils )


 I've just run kdesvn-build and kdeutils seems to build fine here. I added kde-
 utils-devel to CC to reach people knowing the code around the error better.
 Perhaps onyone knows whats going on with your build.

Just as an update, installing python-devel fixed this for me. Why it
is now needed I don't know however.


 Cheers,
 Michael

Regards,
Ben


 -- Found Python executable: /usr/bin/python2.6
 -- Found Python version: 2.6.2
 -- Found Python library: PYTHON_LIBRARY-NOTFOUND

 Build error follows.

 Regards,
 Ben

 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::keyPressed(QString const, Meter const*)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:2055: undefined
 reference to `KarambaPython::keyPressed(Karamba*, Meter const*,
 QString const)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::currentDesktopChanged(int)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1894: undefined
 reference to `KarambaPython::desktopChanged(Karamba*, int)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::receivedStdout(K3Process*, char*, int)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1815: undefined
 reference to `KarambaPython::commandOutput(Karamba*, int, char*)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::processExited(K3Process*)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1804: undefined
 reference to `KarambaPython::commandFinished(Karamba*, int)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::startupRemoved(KSharedPtrStartup)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1793: undefined
 reference to `KarambaPython::startupRemoved(Karamba*, Startup*)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::startupAdded(KSharedPtrStartup)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1782: undefined
 reference to `KarambaPython::startupAdded(Karamba*, Startup*)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::taskRemoved(KSharedPtrTask)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1771: undefined
 reference to `KarambaPython::taskRemoved(Karamba*, Task*)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::taskAdded(KSharedPtrTask)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1760: undefined
 reference to `KarambaPython::taskAdded(Karamba*, Task*)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::activeTaskChanged(KSharedPtrTask)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1749: undefined
 reference to `KarambaPython::activeTaskChanged(Karamba*, Task*)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::passMenuItemClicked(QAction*)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1669: undefined
 reference to `KarambaPython::menuItemClicked(Karamba*, KMenu*, long)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::currentWallpaperChanged(int)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1534: undefined
 reference to `KarambaPython::wallpaperChanged(Karamba*, int)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::closeWidget()':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1380: undefined
 reference to `KarambaPython::widgetClosed(Karamba*)'
 CMakeFiles/superkaramba.dir/karamba.o: In function `Karamba::step()':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:527: undefined
 reference to `KarambaPython::widgetUpdated(Karamba*)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::hoverMoveEvent(QGraphicsSceneHoverEvent*)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:2009: undefined
 reference to `KarambaPython::widgetMouseMoved(Karamba*, int, int,
 int)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::passEvent(QEvent*)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1968: undefined
 reference to `KarambaPython::meterClicked(Karamba*, Meter*, int)'
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1953: undefined
 reference to `KarambaPython::meterClicked(Karamba*, QString, int)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::wheelEvent(QGraphicsSceneWheelEvent*)':
 /home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1985: undefined
 reference to `KarambaPython::widgetClicked(Karamba*, int, int, int)'
 CMakeFiles/superkaramba.dir/karamba.o: In function
 `Karamba::mousePressEvent

KDEUtils build broken for extended period of time

[Ben Cooksley]

Hi all,

Is there any reason why it has not been possible to build kdeutils for
some time? ( couple of days at least ). Going back to a previously
working KDEUtils revision isn't sufficient to fix it either, so I
suspect it is caused by a change in another module, which concurs with
the following strange CMake output ( from a fresh build tree if you're
wondering, and I have no changes on KDELibs or KDEUtils )

-- Found Python executable: /usr/bin/python2.6
-- Found Python version: 2.6.2
-- Found Python library: PYTHON_LIBRARY-NOTFOUND

Build error follows.

Regards,
Ben

CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::keyPressed(QString const, Meter const*)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:2055: undefined
reference to `KarambaPython::keyPressed(Karamba*, Meter const*,
QString const)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::currentDesktopChanged(int)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1894: undefined
reference to `KarambaPython::desktopChanged(Karamba*, int)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::receivedStdout(K3Process*, char*, int)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1815: undefined
reference to `KarambaPython::commandOutput(Karamba*, int, char*)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::processExited(K3Process*)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1804: undefined
reference to `KarambaPython::commandFinished(Karamba*, int)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::startupRemoved(KSharedPtrStartup)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1793: undefined
reference to `KarambaPython::startupRemoved(Karamba*, Startup*)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::startupAdded(KSharedPtrStartup)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1782: undefined
reference to `KarambaPython::startupAdded(Karamba*, Startup*)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::taskRemoved(KSharedPtrTask)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1771: undefined
reference to `KarambaPython::taskRemoved(Karamba*, Task*)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::taskAdded(KSharedPtrTask)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1760: undefined
reference to `KarambaPython::taskAdded(Karamba*, Task*)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::activeTaskChanged(KSharedPtrTask)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1749: undefined
reference to `KarambaPython::activeTaskChanged(Karamba*, Task*)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::passMenuItemClicked(QAction*)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1669: undefined
reference to `KarambaPython::menuItemClicked(Karamba*, KMenu*, long)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::currentWallpaperChanged(int)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1534: undefined
reference to `KarambaPython::wallpaperChanged(Karamba*, int)'
CMakeFiles/superkaramba.dir/karamba.o: In function `Karamba::closeWidget()':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1380: undefined
reference to `KarambaPython::widgetClosed(Karamba*)'
CMakeFiles/superkaramba.dir/karamba.o: In function `Karamba::step()':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:527: undefined
reference to `KarambaPython::widgetUpdated(Karamba*)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::hoverMoveEvent(QGraphicsSceneHoverEvent*)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:2009: undefined
reference to `KarambaPython::widgetMouseMoved(Karamba*, int, int,
int)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::passEvent(QEvent*)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1968: undefined
reference to `KarambaPython::meterClicked(Karamba*, Meter*, int)'
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1953: undefined
reference to `KarambaPython::meterClicked(Karamba*, QString, int)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::wheelEvent(QGraphicsSceneWheelEvent*)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1985: undefined
reference to `KarambaPython::widgetClicked(Karamba*, int, int, int)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::mousePressEvent(QGraphicsSceneMouseEvent*)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1862: undefined
reference to `KarambaPython::widgetClicked(Karamba*, int, int, int)'
CMakeFiles/superkaramba.dir/karamba.o: In function
`Karamba::slotToggleConfigOption(QObject*)':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:1565: undefined
reference to `KarambaPython::menuOptionChanged(Karamba*, QString,
bool)'
CMakeFiles/superkaramba.dir/karamba.o: In function `Karamba::startKaramba()':
/home/ben/kdesvn/kdeutils/superkaramba/src/karamba.cpp:486: undefined
reference to 

Broken compilation of KDENetwork module for excessive period of time due to Kopete

[Ben Cooksley]

Hello list,

Since commit 1010594, I have been unable to build the KDENetwork
module, due to changes to the Kopete WLM plugin.
This is because the changes included an addition to the dependencies,
but the CMake find file for this dependency does not check that the
required version is present on the system.

Build Error Message:

/home/trunk/kdesvn/kdenetwork/kopete/protocols/wlm/wlmchatsession.cpp:
In constructor ‘WlmChatSession::WlmChatSession(Kopete::Protocol*,
const Kopete::Contact*, Kopete::ContactPtrList,
MSN::SwitchboardServerConnection*)’:
/home/trunk/kdesvn/kdenetwork/kopete/protocols/wlm/wlmchatsession.cpp:144:
error: ‘ms_snd_card_manager_get_default_capture_card’ was not declared
in this scope

Is there anything that can be done about this? The original committer
has ceased communicating with me, and does not appear to have solved
the problem. I have completely recreated the KDENetwork build system
approximately 6 times, and neither time has fixed the issue.

Please CC me, since I am not subscribed.

Regards,
Ben Cooksley
System Settings Maintainer
KDE Community Forums Administrator
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem