Are you sure this is needed, they get installed in different prefixes so what's the problem?

/usr/lib/kde4/libexec/ksendbugmail
/usr/lib/x86_64-linux-gnu/libexec/kf5/ksendbugmail

You saw the related bug report at https://bugs.kde.org/show_bug.cgi?id=374347 ?

"ksendbugmail is installed into KDE_INSTALL_LIBEXECDIR_KF5, which seems to be set on Windows to 'bin'. At KDE4 times all executables are installed in <install-root>/bin to be findable by dbus services. This requirement is valid for KF5 too so it is required to install the tool with another name ksendbugmail5.exe on Windows."

If "findable by dbus services" is the only argument for polluting bin with libexec binaries on Windows, then it doesn't apply to *everything* in libexec, only to a handful of executables.

lib64/libexec/kauth/backlighthelper
lib64/libexec/kauth/discretegpuhelper
lib64/libexec/kauth/fontinst
lib64/libexec/kauth/fontinst_helper
lib64/libexec/kauth/kalarm_helper
lib64/libexec/kauth/kcmdatetimehelper
lib64/libexec/kauth/kcm_kwallet_helper5
lib64/libexec/kauth/kcmsddm_authhelper
lib64/libexec/kauth/ksysguardprocesslist_helper
lib64/libexec/kdeconnectd
lib64/libexec/kf5/kiod5
lib64/libexec/kf5/kscreen_backend_launcher
lib64/libexec/ktp-auth-handler
lib64/libexec/ktp-filetransfer-handler
lib64/libexec/ktp-proxy
lib64/libexec/ktp-text-ui

Everything else can still go into libexec, no?

I did not took a look into every location where an executable is installed into KDE_INSTALL_LIBEXECDIR_KF5, but I guess on Windows any application which may be started *only* by a KF5 provided api may be located in the libexec dir ; all other needs to stay into <install-root>/bin (or <install-root> in case there is no bin dir in the installation I saw in some null soft based installations like digikam)

If you really want to have executables in libexec dir on Windows too a patch is required to change KDE_INSTALL_LIBEXECDIR_KF5 to xxx/libexec and to introduce a different cmake variable for installing all other executables, which points to the "bin"-dir on Windows and the same path as KDE_INSTALL_LIBEXECDIR_KF5 on other platforms. Then every occurrance of KDE_INSTALL_LIBEXECDIR_KF5 in kf5 libraries needs to be checked and replaced by this variable

Adding '5' postfix to 4 executables (see https://bugs.kde.org/showdependencytree.cgi?id=373928&hide_resolved=1) would be a more simple solution from my opinion.

Well I would accept a compromise, where dbus-started services get installed in bin on Unix as well.
Which means still only two install vars and dirs: bin and libexec. With consistency between Unix and Windows about whether a given executable gets installed into bin or libexec.

It's easier to remember the rule "dbus-started services go into bin" than "you need to add a '5' prefix even to libexec binaries even though they are in a kf5 subdir so it looks like this shouldn't be necessary".

The question is, can you add libexec to the path (so that findExecutable works) only for kf5-based executables (so that kde4 apps don't break) ?

no

If not, then your description of the problem was incorrect and this is not just about dbus-started services but about difficulties locating the libexec dir on Windows.

this problem has already been solved in KF5 by installing all 'libexec' executables into bin. The remaining issue the name clash this bug describes.
You may state: 'If this is a windows only problem the solve it on Windows only' - I already thought about that by wrapping all the hunks in this patch with #ifdef Q_OS_WIN32 ... #endif - would that better ?

In any discussion about libexec related issues we keep hitting the fact that >there is no standard env var for it. Maybe we need a custom one (which could >then be KF5_LIBEXEC_PATH, so it won't conflict with KF6).

Because every KDE application installers bundles a complete KF5/Qt5 runtime using system or user based environments are not a possible way to solve path issues. Setting something like KF5_LIBEXEC_PATH would work for one installation, but not for all other installations. Therefore in KDE4 times all path calculations are based on the runtime install path (by detecting the path of shared libraries e.g. kdelibs or dbus or executables like dbus-daemon.

In fact any KDE on Windows installation is completly portable.

So bin isn't in %PATH%, but found relatively to the app being run?

This makes me wonder if libexec could be bin/libexec/kf5/ on Windows, relative too.

Then we could have an ECM-provided string that expands to
CMAKE_INSTALL_PREFIX "/" KF5_LIBEXEC_INSTALL_DIR on Unix (i.e. absolute), and
KF5_LIBEXEC_INSTALL_DIR on Windows (i.e. relative).

Wouldn't this keep the Unix/Windows differences to a minimum?

So bin isn't in %PATH%, but found relatively to the app being run?

yes

This makes me wonder if libexec could be bin/libexec/kf5/ on Windows, relative too.

This requires to add support for finding executables located in libexec based on install root e.g. instead of using

QString command = QStandardPaths::findExecutable(QStringLiteral("ksendbugmail5"));

to use something like this

QString installroot = getKF5Prefix(); // similar to what is implemented in KDE4 (see https://cgit.kde.org/kdelibs.git/tree/kdecore/kernel/kkernel_win.cpp?h=KDE/4.14#n97)
QString command = QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"), installRoot + QStringLiteral("bin/libexec/kf5/"));
or
QString command = QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"), installRoot + QStringLiteral(KF5_LIBEXEC_INSTALL_DIR));

if KF5_LIBEXEC_INSTALL_DIR is a relative path to the requested subdir based on the install root.

Then we could have an ECM-provided string that expands to
CMAKE_INSTALL_PREFIX "/" KF5_LIBEXEC_INSTALL_DIR on Unix (i.e. absolute), and
KF5_LIBEXEC_INSTALL_DIR on Windows (i.e. relative).

Wouldn't this keep the Unix/Windows differences to a minimum?

Related to install layout it would be reduce the difference, but on the source code side you need to add detecting the install root to any code where an executable located in libexec needs to be searched, which increases the differences in the source code.

The complete code fragment would look like
#ifndef Q_OS_WIN32

QString command = QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"));
if (command.isEmpty()) {
    command = QFile::decodeName(CMAKE_INSTALL_PREFIX "/" KF5_LIBEXEC_INSTALL_DIR "/ksendbugmail");

#else

QString searchPath = getKF5Prefix() + QStringLiteral(KF5_LIBEXEC_INSTALL_DIR);
QString command = QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"), searchPath);

#endif

An optimization would be to call getKF5Prefix() on non Windows too, which returns CMAKE_INSTALL_PREFIX "/". This reduced the above mentioned code to

QString searchPath = getKF5Prefix() + QStringLiteral(KF5_LIBEXEC_INSTALL_DIR);
QString command = QStandardPaths::findExecutable(QStringLiteral("ksendbugmail"), searchPath);

BTW: You mentioned that KF5_LIBEXEC_INSTALL_DIR is 'bin/libexec/kf5/' on Windows, Should it not be lib/libexec/kf5 ? On unix this is located in 'lib[64]/libexec/kf5 ' - why this difference ?

In D5173#124620, @habacker wrote:

BTW: You mentioned that KF5_LIBEXEC_INSTALL_DIR is 'bin/libexec/kf5/' on Windows, Should it not be lib/libexec/kf5 ? On unix this is located in 'lib[64]/libexec/kf5 ' - why this difference ?

Windows only looks in system locations (as specified in %PATH%) and the current directory of the binary for library (dll) files. Therefore on Windows *.dll files are stored in $prefix/bin/ and not $prefix/lib. As a consequence the libexec directory is also relocated to $prefix/bin/

From my understanding of this on Linux/FreeBSD the install destinations for these binaries are different. On Windows you should have one install prefix per application and you can't mix Qt versions in an application.

So i'm not seeing how we end up with a clash here?

Looking into the bug report gaves the answer:

file /usr/i686-w64-mingw32/sys-root/mingw/bin/ksendbugmail.exe from install of mingw32-libKF5XmlGui5-5.26.0-3.1.noarch conflicts with file from package mingw32-kdelibs4-4.14.60-11.4.noarch

For the recored: this could happens on obs, where stable releases for umbrello and kmymoney on Windows are build.

So Ben's comment is offtopic.