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.

For a moment I suspected the seen error could also be due to find_file doing this:
"A cache entry named by <VAR> is created to store the result of this command. If the full path to a file is found the result is stored in the variable and the search will not be repeated unless the variable is cleared."
https://cmake.org/cmake/help/v3.0/command/find_file.html

So if the plasma-desktop build dir still had a CMake cache from a time when the install prefix of KF5 was /usr, but then was changed meanwhile to /opt/kde, the cache might have broken outdated data and thus making the configure_file() throwing the error it did.

But that theory was just declared unapplyable as
<bshah[m]> frinring: nope, it's clean build and clean SSD

(kdelibs_SOURCE_DIR has been meanwhile removed from KF5InitMacros.cmake in https://commits.kde.org/kinit/3bcf7a1b3421d3e528291b9e6fd606c95db15c2c)

Moving to kinit, as for now I suspect that if there is a bug, it is triggered by the caching of the _KDE5INIT_DUMMY_FILEPATH variable after the initial invocation of kf5_add_kdeinit_executable(). Though I cannot see why later invocations would expect another file to be found.
Unless there is some cross-compilation environment prefix change magic happen in between, which then invalidates initial result?

So additional question:
Was this is normal build against the local system, or some cross-compilation setup?

If you can provide the information requested, please add it.

To further investigate this issue, KDE developers need the information requested in comment #3. If you can provide it, or need help with finding that information, please add a comment.

No response; changing status. If you have new information, please add a comment.

Sorry for lack of response here, I had provided Friedrich information in IRC and we agreed that this bug is invalid.