kcoreaddons_add_plugin executable/plugin directory conflict

Friedrich W. H. Kossebau kossebau at kde.org
Mon May 11 13:07:28 BST 2020


Am Montag, 11. Mai 2020, 10:21:10 CEST schrieb Daniel Vrátil:
> Hi all,
> 
> I'm moving some plugins in kaddressbook and I ran into a problem with
> kcoreaddons_add_plugin:

Problem found because you require ECM >= 5.38, triggering the use of the 
CMAKE_BUILD_DIR/bin as executable artifact placement dir by KDECMakeSettings, 
compare https://api.kde.org/ecm/kde-module/KDECMakeSettings.html#build-settings

> I have this in the plugin CMakeLists.txt:
> 
> kaddressbook_add_plugin(
> 	kaddressbook_importexportvcardplugin
> 	JSON kaddressbook_importexportvcardplugin.json
> 	SOURCES ${kaddressbook_importexport_vcard_SRCS}
> 	INSTALL_NAMESPACE kaddressbook/importexportplugin
> )
> 
> When I run make on the entire project, it fails with
> 
> [ 65%] Linking CXX shared module ../../../../bin/kaddressbook/
> importexportplugin/kaddressbook_importexportvcardplugin.so
> ld: error: cannot open output file ../../../../bin/kaddressbook/
> importexportplugin/kaddressbook_importexportvcardplugin.so: Not a directory
> 
> Alternatively, if a plugin gets created first, it fails on
> 
> [ 96%] Linking CXX executable ../bin/kaddressbook
> ld: error: cannot open output file ../bin/kaddressbook: Is a directory
> 
> I realized the problem is that CMake is unable to create the plugin in
> $BUILDDIR/bin/kaddressbook/importexportplugin/ directory, because there's
> already $BUILDDIR/bin/kaddressbook executable (or vice versa).
> 
> I would assume this is a very common problem - having plugins "namespaced"
> in the same directory as is the name of the program (and executable).
> Should the macro maybe put the plugins into
> "$BUILDDIR/bin/plugins/$INSTALL_NAMESPACE/"? Would that make the lookup any
> more complicated?
> 
> Is there some known solution/workaround to this? I'd prefer not to have to
> rename the executable or the plugins namespaces, since having different name
> for the program and the plugin "namespace" somewhat defeats the purpose of
> a namespace...

kdeconnect solved this by renaming before, but not with much happiness.

Okular recently in some (later discarded) patches raising min ECM was about to 
hit the same issue as well, there the hint by David was to manually overwrite 
the LIBRARY_OUTPUT_DIRECTORY property for the plugin targets.

Open question is how any changed path there effects the goal of being able to 
run tests against the uninstalled plugins...

Cheers
Friedrich




More information about the Kde-frameworks-devel mailing list