Making kdefx static
Matthew Woehlke
mw_triad at users.sourceforge.net
Fri Aug 3 21:34:50 BST 2007
Thiago Macieira wrote:
> Andreas Pakulat wrote:
>>> Therefore, I can think of a few options:
>>> 1. Rename the useful bits K3* and remove what we can
>>> 2. Make the library static
>>> 3. Both?
>>>
>>> Option 1 would mean we are stuck with stale (and ugly) code for the
>>> life of KDE4. Option 2 means we can yank kdefx later without affecting
>>> BC. Option 3 is the same as 2 except that 2 is (or is very nearly) SC,
>>> while 1 and 3 require minor code changes for all users (i.e. adding
>>> "3" to all uses).
>> As far as I know the plan is to introduce Blitz from Mosfet as
>> replacement for kdefx in KDE 4.0 and replace that by Quasar for 4.1
>> (when its ready). Blitz would be created as static library so its easier
>> to remove later on and AFAIK Mosfet wanted to help in the porting
>> effort. This would allow to svn rm kdefx completely for kde4.0
>
> Forget "static".
>
> You can't link a static library to a dynamic library.
Well obviously we need to fix that :-). But the impression I got is that
more apps use it than libraries (or at least, I have some idea of what
the lib users are and know they can - and should - be fixed). However...
> Leave it a normal, dynamic, shared library. Just don't install the headers
> and remove its finding from the KDE cmake macros.
...that doesn't work at all because apps use it, and therefore we
*cannot* remove the headers (take a look at lxr to get an idea of the
work required). So unless I am missing something, the choice is 'static'
(fixing lib users, as above) or 'stuck with it until KDE5'.
--
Matthew
"Non sequitor. Your facts are out of order." -- Nomad
More information about the kde-core-devel
mailing list