I think the issue is the

find_package(ECM 5.15.0 REQUIRED CONFIG)

to

find_package(ECM 5.49.0 REQUIRED CONFIG)

change

If I don't do that, it still links.
I think some changed ECM behavior is not to your liking.

In D15076#315335, @cullmann wrote:

I think the issue is the

find_package(ECM 5.15.0 REQUIRED CONFIG)

to

find_package(ECM 5.49.0 REQUIRED CONFIG)

change

If I don't do that, it still links.
I think some changed ECM behavior is not to your liking.

thanks @cullmann . It's strange somehow... I'll proceed with ECM 5.15 now and keep this review open a bit. Maybe somebody else knows what's going on here.

Perhaps other frameworks people know the exact cause.

I don't know the cause myself but the ECM version works up until 5.38.0 in my own testing. So presumably the change in behavior is something introduced in that release of ECM?

The ECM documentation points to a specific change that may be related: https://api.kde.org/ecm/kde-module/KDECMakeSettings.html#build-settings

Using the KDE_SKIP_BUILD_SETTINGS option that is described just leads to different build failures for me, however. I think it's just a matter of adjusting some buildsystem-specific paths to reflect the new locations with newer ECM.

In D15076#315506, @mpyne wrote:

I don't know the cause myself but the ECM version works up until 5.38.0 in my own testing. So presumably the change in behavior is something introduced in that release of ECM?

Then that's easy: 7af93dd2

Finding why the cantor build fails requires more output (VERBOSE=1 make -j1) after removing CMakeCache.txt

In D15076#315583, @cgiboudeaux wrote:

In D15076#315506, @mpyne wrote:

I don't know the cause myself but the ECM version works up until 5.38.0 in my own testing. So presumably the change in behavior is something introduced in that release of ECM?

Then that's easy: 7af93dd2

Finding why the cantor build fails requires more output (VERBOSE=1 make -j1) after removing CMakeCache.txt

With this I'm getting

[ 25%] Linking CXX shared module ../../../bin/cantor/backends/cantor_nullbackend.so
cd /home/alex/Projekte/cantor/build_debug/src/backends/null && /usr/bin/cmake -E cmake_link_script CMakeFiles/cantor_nullbackend.dir/link.txt --verbose=1
/usr/bin/c++  -fPIC -std=c++0x -fno-operator-names -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -std=c++0x -fno-operator-names -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -pedantic -Wsuggest-override -Wlogical-op -Wzero-as-null-pointer-constant -fexceptions -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags  -shared  -o ../../../bin/cantor/backends/cantor_nullbackend.so CMakeFiles/cantor_nullbackend.dir/nullbackend.cpp.o CMakeFiles/cantor_nullbackend.dir/nullsession.cpp.o CMakeFiles/cantor_nullbackend.dir/nullexpression.cpp.o CMakeFiles/cantor_nullbackend.dir/nullcompletionobject.cpp.o CMakeFiles/cantor_nullbackend.dir/cantor_nullbackend_automoc.cpp.o ../../../bin/libcantorlibs.so.18.11.70 /usr/lib64/libKF5KIOFileWidgets.so.5.49.0 /usr/lib64/libKF5Bookmarks.so.5.49.0 /usr/lib64/libKF5Solid.so.5.49.0 /usr/lib64/libKF5KIOWidgets.so.5.49.0 /usr/lib64/libKF5KIOCore.so.5.49.0 /usr/lib64/libQt5Concurrent.so.5.11.1 /usr/lib64/libKF5JobWidgets.so.5.49.0 /usr/lib64/libKF5XmlGui.so.5.49.0 /usr/lib64/libKF5Completion.so.5.49.0 /usr/lib64/libKF5IconThemes.so.5.49.0 /usr/lib64/libKF5Archive.so.5.49.0 /usr/lib64/libKF5ItemViews.so.5.49.0 /usr/lib64/libKF5Service.so.5.49.0 /usr/lib64/libKF5ConfigWidgets.so.5.49.0 /usr/lib64/libKF5ConfigGui.so.5.49.0 /usr/lib64/libKF5ConfigCore.so.5.49.0 /usr/lib64/libKF5I18n.so.5.49.0 /usr/lib64/libKF5WidgetsAddons.so.5.49.0 /usr/lib64/libKF5Codecs.so.5.49.0 /usr/lib64/libKF5Auth.so.5.49.0 /usr/lib64/libKF5CoreAddons.so.5.49.0 /usr/lib64/libQt5DBus.so.5.11.1 /usr/lib64/libQt5Widgets.so.5.11.1 /usr/lib64/libQt5Gui.so.5.11.1 /usr/lib64/libQt5Network.so.5.11.1 /usr/lib64/libQt5Xml.so.5.11.1 /usr/lib64/libQt5Core.so.5.11.1 -Wl,-rpath,/home/alex/Projekte/cantor/build_debug/bin 
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot open output file ../../../bin/cantor/backends/cantor_nullbackend.so: Not a directory

This error for cantor_nullbackend.so I always get for the second and later make calls. The first fails for cantor_maximabackend.so.

In D15076#315797, @asemke wrote:

/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot open output file ../../../bin/cantor/backends/cantor_nullbackend.so: Not a directory

OK, I can reproduce and ironically, the issue is caused by a fix in kcoreaddons to fix a runtime issue with the commit I mentioned before.

Short version:
the cantor stuff uses the kcoreaddons_add_plugin macro with the INSTALL_NAMESPACE parameter pointing to "cantor/backends" This creates a cantor/backends subdir in ${CMAKE_BINARY_DIR}/bin/

The build fails locally because the linker can't create the cantor executable in ${CMAKE_BINARY_DIR}/bin. There's already a directory using the same name.

In D15076#315803, @cgiboudeaux wrote:

In D15076#315797, @asemke wrote:

/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot open output file ../../../bin/cantor/backends/cantor_nullbackend.so: Not a directory

OK, I can reproduce and ironically, the issue is caused by a fix in kcoreaddons to fix build with the commit I mentioned before.

Short version:
the cantor stuff uses the kcoreaddons_add_plugin macro with the INSTALL_NAMESPACE parameter pointing to "cantor/backends" This creates a cantor/backends subdir in ${CMAKE_BINARY_DIR}/bin/

The build fails locally because the linker can't create the cantor executable in ${CMAKE_BINARY_DIR}/bin. There's already a directory using the same name.

I see. Thanks for the explanation. Since there is no urgent need to use for ECM 5.49, we can stick to 5.15 for a moment. Or are there any reasons not to do so?

David, Elvis, what's the nicest way to fix this ? (https://phabricator.kde.org/D15076#315803 for the details)

Hmm, I can only think of renaming the cantor folder to something else (but that would probably be annoying for packagers...)

Yes, maybe rename cantor to cantorplugins?

The plugins dir already has some subdirs named plasmacalendarplugins or ruqolaplugins.

Of course the loading code has to be adapted accordingly.

We need the plugins in the bin dir for autotests to be able to locate them. Although ECM's commit 7d6d5b1 makes me wonder how it's all supposed to work now (before that commit I would have said that we can just move the stuff to bin/plugins/ to avoid this clash, and adjust QT_PLUGIN_PATH in ECMAddTests). I need to research this further, I guess Windows finds them in the bin dir and other OSes do need QT_PLUGIN_PATH. In which case moving them won't be an option.

@dfaure That change was an urgent measure on my part, in order to allow KDevelop tests on the CI system to find something, and be able to complete successfully. At the moment they all hang due to being unable to find any plugins (they have an error popup...). The lack of available plugins was a result of the ECM code completely breaking QT_PLUGIN_PATH - this is why some Framework tests fail as well, being unable to find any KIO plugins (disabling this same logic in ECM was what gave me the output I emailed to you about a week ago). We'll find out if my urgent measure was successful next time the Dependency Builds run through.