[patch] Re: WITH_PREFIX for kdemodules?
Jarosław Staniek
js at iidea.pl
Fri Nov 9 01:15:11 CET 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)
why?
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-windows/attachments/20071109/f0d79835/attachment.ksh
More information about the Kde-windows
mailing list