patch: Makefile cleanup

[Simon Hausmann]

On Thu, Nov 29, 2001 at 04:21:49PM +0100, F at lk Brettschneider wrote:
> Hi,
> 
> The aim is to easy development of KDevelop as well as reducing startup
> time and memory use.
> 
> For instance 2 reasons:
> - using shared libs I don't need to link the whole kdevelop just when I
> change a file in the debugger lib as well as a make install of a huge
> kdevelop binary.

At the cost of a bigger packager, slower code and longer startup
time?

FWIW a kdevelop binary using my patch is 2.9MB here. I wouldn't call 
that huge.

> - I don't want the vc stuff loaded in memory when my projects don't use
> it. Using shared libs it's not loaded, just on demand.

That's not true. ELF binaries, just like ELF shared libraries (in fact 
they are the same) are loaded into memory using the mmap(2) system call, 
which means that only those pages of the file that are actually accessed 
get read into memory. This is the most efficient way, and it's the 
same for binaries and shared libraries (because they are basically
the same format, ELF on todays machines) . Shared libraries in
contrast to plain binaries have the disadvantage that their code
needs to be position independent (which makes it slower and bigger)
and it usually involves resolving and relocating symbols at startup, 
as well as actually finding the right shared library (obeying 
LD_LIBRARY_PATH and the ld.so cache settings) .

Especially the last point becomes more important when shared
libraries are installed for no reason (read: when they actually
aren't used by different binaries) , because then they fill up the
library directory. Many distros install KDE with /usr as prefix,
which means that /usr/lib has another six unshared libraries in case
of kdevelop.

My opinion is: Share code when there is something to share. Otherwise
there's no advantage.


Simon