WITH_PREFIX for kdemodules?

Jaroslaw Staniek js at iidea.pl
Mon Oct 29 10:28:50 CET 2007

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 

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-windows mailing list