kcoreaddons_add_plugin executable/plugin directory conflict

[David Faure]

On lundi 11 mai 2020 14:07:28 CEST Friedrich W. H. Kossebau wrote:
> 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).

I didn't anticipate this because that name conflict with an executable doesn't happen in KDE Frameworks,
where the install namespace starts with kf5 :(

> > Should the macro maybe put the plugins into
> > "$BUILDDIR/bin/plugins/$INSTALL_NAMESPACE/"? Would that make the lookup
> > any more complicated?

Yes, at least that was the initial reasoning, because "." is a default search path for plugins in Qt. But see below.

> > 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...

Well, for kontact I used kontact5 as plugin namespace, to avoid ever risking a mixup between qt5/kf5-based plugins and qt6/kf6-based plugins.
This sounds like a good solution to both problems.

But otherwise:

I later realized that while '.' is in the search path, it has less priority than QT_PLUGIN_PATH,
so it was picking up my installed plugins instead of the locally built ones.
So now modules/ECMAddTests.cmake sets the QT_PLUGIN_PATH env var for when running tests (https://phabricator.kde.org/D8660).
Therefore we could indeed move all plugins to a subdir.
The attached patches do that.

We however lose the magic of finding plugins in $PWD, when running a test/program directly (rather than via ctest)
(i.e. like an IDE would run them), if the plugins aren't otherwise available in the system.

So I'm thinking.... how about just adding a 5? :-)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcoreaddons.diff
Type: text/x-patch
Size: 850 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200512/73f9475c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecm.diff
Type: text/x-patch
Size: 659 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200512/73f9475c/attachment-0001.bin>