[patch] Re: WITH_PREFIX for kdemodules?

Jarosław Staniek js at iidea.pl
Fri Nov 9 00:15:11 GMT 2007

Alexander Neundorf said the following, On 2007-11-08 21:51:
> On Thursday 08 November 2007, Allen Winter wrote:
>> On Wednesday 07 November 2007 15:42:28 Alexander Neundorf wrote:
>>> On Monday 05 November 2007, Alexander Neundorf wrote:
>>>> On Monday 05 November 2007, you wrote:
>>> ...
>>>>> And I agree. We shouldn't be linking to plugins.
>>>> So, does anybody else still have objections against removing
>>>> "WITH_PREFIX" ?
>>> So, conclusion: I'll remove the "WITH_PREFIX" option and no plugins will
>>> have the "lib" prefix anymore, I'll commit next monday.
>> This coming Monday is a bad time.  We are trying to tag a Development
>> Platform. I think this will cause a lot of breakage in the apps, which will
>> cause extra frustration and delays we don't need at this time.
> So how about the monday after that ?
> It only changes the name of the created plugin, and if I understood correctly 
> they are searched in both versions currently, so why do you think it could 
> cause a lot of breakage ?
> Jaroslow, what do you think ?

I'll try to present as simple solution as possible from my POV.

Surprisingly, I'd go with
"1) leave it as it is and keep the "WITH_PREFIX" option, so some plugins have
the "lib" prefix and others don't"

(for now)


1. it's a tagging time

2. I've already cooked a code (the patch is attached; please review) that:

(a) adds a "lib" prefix for an init_ symbol name in case when a symbol without 
  the "lib" prefix is not found ; see part of the patch related to klibrary.cpp

(b) by the way it simplifies some redundant windows lib/plugin loading code 
from kdecore/util/

- -
re linking to modules:

I am unsure whether allowing linking to modules is a big win, when the price 
paid is a bit more obfuscated design for kde dev platform's runtime.

But note, to use symbols from a module that is also used as a lib, we need to 
export symbols. So we should not forget that app_export.h export files have to 
contain another FOOMODULE_EXPORT macro as well.

We need to somehow force cmake to define a kind of MAKE_***_LIB macro for us 
while compiling such special modules to export expected symbols other than its 
entry point. Does it work already?

E.g. note that on windows library binaries go to bin/
(${LIB_INSTALL_DIR} == bin) so binaries of the special modules would go there 
as well, something not very appealing (we want to avoid a need for multiple 
locations for binaries what would force us to modify the $PATH so we install 
.exe's and .dll's in the same place).

The next step would be to use lib prefix _only_ when module is also used as a lib.

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: util.patch
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071109/f0d79835/attachment.ksh>

More information about the kde-core-devel mailing list