cygwin-patches for kde 3.4.1

[Thiago Macieira]

David Faure wrote:
>On Friday 17 June 2005 14:18, Thiago Macieira wrote:
>> The patch is correct. If you use libkdecore stuff in your program
>> (say, KURL), you should add explicitly -lkdecore to your link
>> libraries. (Whether it is -lkdecore or $(LIB_KDECORE) is irrelevant)
>
>Well if you use KIO, which obviously uses KURL too, you shouldn't have
> to mention kdecore explicitely. We have cleaned up Makefile.ams
> everywhere to only list the highest level dependency, no point in a
> 10-km-long lib list.

On the other hand, suppose you linked to KIO, but used something from a 
library libkio uses directly or indirectly (let's call it third-party 
libxml). If KIO ever stops using that library, for whatever reason, you 
program will fail to link. Not only that, it will also fail to run if you 
upgrade libkio, without touching the program.

Hence the need to specify all dependencies. I suggested in the namespace 
thread that we split the libraries into namespaces. An also interesting 
idea is to split headers into separate subdirectories (like Qt4). This 
will make it easier on the developer to understand what he needs to link 
against.

Another way out would be to add to our Binary Compatibility rules that 
released libraries (public and private alike) may never drop 
dependencies. I.e., if libkio links to libxml when KDE 4 is released, 
then it will have to continue linking to libxml until KDE 5, even if 
something faster, better and more efficient comes along.

>> libtool will add the dependency libraries if and only if the .la file
>> is present. IIUC, the Cygwin people aren't using them. And we're
>> talking about replacing libtool in the build-system thread, which
>> means .la would be gone.
>
>If we ever drop libtool, we can simply make $(LIB_KIO) include -lkio
> -lkdeui -lkdecore. Still no reason to bloat the Makefile.am.

That might be feasible for kdelibs, but might be really hard for other 
modules and applications unless we create an equivalent .la file.

If we do that, we end up at the other end of the problem: every library 
will be listed. I don't want every library to be linked against: I want 
only those that my program uses.

The same rationale for libxml can be used: if I don't use libxml in my 
KIO-using program, why should my program explicitly link to libxml? In 
special, if KIO drops libxml (for whatever reason, directly or 
indeirectly), my program should automatically stop loading libxml.

(The behaviour of the last paragraph is accomplished by ld's --as-needed)

>> That's not a problem with ELF because it is forgiving and will load
>> the libraries. But Win32's COFF PE file format (or, at least, Cygwin'
>> s implementation of it) is braindamaged and requires explicit listing
>> of ALL libraries, including kernel32, gdi32, commctrl, etc. that KDE
>> will never have it its Makefiles.
>
>That's still something the build system can do for you. The point is to
>make things easy for the developer, especially when it's as easy as
>patching acinclude.m4.in once and for all.

The linker should solve this here.

I remember the few months I used Cygwin (I was trying to compile with 
wxWindows). It was impractical because every application I tried linking, 
I had to run the (slow) compiler 10 times to work out the unresolved 
symbols, plus nm & grep to find out which library had it.

-- 
  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: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050617/f6ec529f/attachment.sig>