Fwd: KDE/kdebase/libkonq

[Thiago Macieira]

Alexander Neundorf wrote:
>On Wednesday 01 March 2006 14:24, David Faure wrote:
>> On Wednesday 01 March 2006 13:48, Thiago Macieira wrote:
>> > Being pedantic:
>> > ${LIB_KPARTS} should expand to "kparts" only. The build system has
>> > to figure out kparts' dependencies on its own.
>
>AFAIK cmake does this, if kparts has been built in the current project
> (i.e. while building kdelibs, cmake should be able to add the libs
> which kparts depends on).

That's what I'm asking for.

>I didn't test this, but I think this doesn't work when building e.g.
> kdebase.

If that is so, you'll have to install a file along with the libraries 
saying what their dependencies are. Think of the libtool .la files.

On ELF systems using dynamic libraries, where such nonsense is not 
necessary, don't install the dependency libraries.

To our Windows developers: how does MSVC solve such nonsense? Can it link 
to a DLL without requiring that DLL's dependencies to be listed? Or does 
it require you to know what dependencies a DLL has?

Example: your project is App and you're linking to DllA and DllB. DllA 
uses code from DllC, but you don't in your application. What do you need 
to know to link your App in MSVC?

>The cannonical way would be in FindKDE4.cmake:
>
>FIND_LIBRARY(KDE4_KPARTS_LIBRARY NAMES kparts PATHS ...)
>SET( KDE4_KPARTS_LIBRARIES ${KDE4_KPARTS_LIBRARY} ${KDE4_KIO_LIBRARIES}
> )
>
>and then KDE4_KPARTS_LIBRARIES should be used.
>
>What do you think about this ?

I think we can compromise: the KParts variable should expand to the KParts 
library and any library whose API it exposes. Unlike C libraries, with 
C++ you can't call a method that takes a QString without linking to Qt. 
So the KPARTS variable should expand to (probably) "kparts kio kdeui 
kdecore QtCore QtGui". This is also the information that should be saved 
in the installed kparts.pc file (pkg-config).

But as we don't expose any classes from zlib, it should not expand to "z". 
If, in the future, we decide to switch to libbz2, why should applications 
still load libz?

The ideal would be that, if KParts doesn't expose any classes from 
libkdecore in its public API, KPARTS shouldn't include "kdecore", but I 
guess this will be rather difficult to maintain.

The immediate consequence of this is that any developers writing code that 
uses KPARTS and zlib will need to explicitly say they use zlib in their 
CMakeFiles.txt files.

I think this is reasonable. It's analogous to doing #include <stdio.h> in 
one system where stdio.h includes unistd.h and relying on that fact. Not 
all systems will include unistd.h from stdio.h, so you're not allowed to 
do that: you have to write #include <unistd.h> in your sources if you 
want to use stuff from unistd.h.

This is also more reasonable than the BSDs requiring you to do #include 
<sys/types.h> before you use any header that requires the types defined 
in sys/types.h.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060302/53f9661a/attachment.pgp