https://bugs.kde.org/show_bug.cgi?id=391366
Friedrich W. H. Kossebau <kosse...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WAITINGFORINFO
Status|UNCONFIRMED |NEEDSINFO
--- Comment #1 from Friedrich W. H. Kossebau <kosse...@kde.org> ---
On a quick look I cannot see how the reverted commit and the CMake code for
kaccess with the CMake macros from kinit relate to each other. The macro
kcoreaddons_add_plugin() is not used anywwhere there. If there is causality
that would be some tricky sideeffect otherwise hiding from my quick glance.
With that said, can you tell if this error is repeatable? Does it fail again if
you undo the revert?
What made you try to revert that commit to fix the CMake error? So are there
other hints which might explain (to me) why this change triggers this?
>From looking at the pasted CMake log, I understand this happens:
1. kf5_add_kdeinit_executable() in kaccess fails due to kde5init_dummy.cpp.in
somehow no longer accessable. As result the target kdeinit_kaccess is not
created
2. target_link_libraries() in kaccess fails as the target does not exist.
For a start I am confused to see that the KInit macro used from install prefix
"/opt/kde/" tries to use its helper file from the install prefix "/usr".
Looking at https://cgit.kde.org/kinit.git/tree/KF5InitMacros.cmake, we see that
the file is (given kdelibs_SOURCE_DIR* & KInit_SOURCE_DIR are not set as here
the macro is not used as part of kinit build itself) this boils down to
find_file(_KDE5INIT_DUMMY_FILEPATH NAMES kde5init$_dummy.cpp.in HINTS
${CMAKE_CURRENT_LIST_DIR})
Which by you log message returns the file from
/usr/lib64/cmake/KF5Init/kde5init_dummy.cpp.in
* OT: kdelibs_SOURCE_DIR smells like something which was forgotten to remove
once the KF5 splitting was completed
Here I would check why we get the file from /usr, not /opt/kde/. Possibly the
order of paths checked needs to get a better control.
But still, the file from /usr should work as well, given the content has not
seen commits in years.
Then next there is the configure_file() command which emits the first error,
which resolves in the kaccess call of KF5_ADD_KDEINIT_EXECUTABLE() to this:
configure_file(${_KDE5INIT_DUMMY_FILEPATH}
${CMAKE_CURRENT_BINARY_DIR}/kaccess_dummy.cpp)
And now it gets strange. Just before CMake was able to locate that file, but
now it says it does not exist. No idea how that can happen. And thus also no
idea how this relates to kcoreaddons' kcoreaddons_add_plugin() and the commit
you reverted.
So next to trying if this is reproducable, could you please add some debug log
to kf5_add_kdeinit_executable() to shed some more light onto where cmake starts
to contradict itself, perhaps
message(STATUS "Is ${_KDE5INIT_DUMMY_FILEPATH} there?")
if(EXISTS ${_KDE5INIT_DUMMY_FILEPATH})
message(STATUS "Really there ")
endif()
before the configure_file call.
--
You are receiving this mail because:
You are watching all bug changes.
