WITH_PREFIX for kdemodules?
Jaroslaw Staniek
js at iidea.pl
Mon Oct 29 09:28:50 GMT 2007
Hello
Is there a technical reason (e.g. some tools expect this) to use 'lib' prefix
for kde plugins?
Libs are linked this way if WITH_PREFIX is present in CMakeFile.txt, eg.
kde4_add_plugin(karbonepsexport WITH_PREFIX ${karbonepsexport_PART_SRCS})
Klibloader has problems with this on Windows, and some plugins use lib
prefix, some do not.
kdecore/utils/ code is unnecessary complicated (there are 3 copies of the same
code for removing "lib" prefix) because of the problem, while in the same
time we have the following warning, that's reasonable for me at the moment:
if (hasPrefix)
kDebug(150) << "plugins shouldn't have a 'lib' suffix:" << libname;
-in QString findLibraryInternal(const QString &name, const
KComponentData &cData)
And now:
1. I have improved the code containing these 3 copies.
2. Is it a good idea to refuse loading of plugins with lib prefix, and/or remove
support for WITH_PREFIX from kde4_add_plugin()?
3. I have also fixed a problem with resolving init_* symbol on Windows, where
"*" is a module name without "lib" prefix. I am just adding "lib" for a second
try.
Summing up: If we refuse accepting the lib prefix, we wouldn't need to try to
find init_ symbol and lib names multiple times, regardless of the platform we
run on, and the code will be even more cleaned.
I can provide patches depending on what is our conclusion.
--
regards / pozdrawiam, Jaroslaw Staniek
Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
Kexi & KOffice: http://www.kexi.pl/en, http://www.koffice.org
KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org
More information about the kde-core-devel
mailing list