Making kdefx static

[Matthew Woehlke]

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