kcoreaddons_add_plugin executable/plugin directory conflict

[Daniel Vrátil]

On Tuesday, 12 May 2020 01:20:02 CEST David Faure wrote:
> 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.

Makes sense, I adopted this approach. Thanks, David.

/Dan

> 
> 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? :-)


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200512/ec0c5772/attachment.sig>