From kde-core-devel  Mon Oct 29 09:28:50 2007
From: Jaroslaw Staniek <js () iidea ! pl>
Date: Mon, 29 Oct 2007 09:28:50 +0000
To: kde-core-devel
Subject: WITH_PREFIX for kdemodules?
Message-Id: <4725A7D2.7010605 () iidea ! pl>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=119365039617248

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