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 | dvra...@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
signature.asc
Description: This is a digitally signed message part.
