cvs commit: src/gnu/lib/libreadline/readline Makefile

[Ruslan Ermilov]

On Mon, Oct 18, 2004 at 01:27:47PM +0400, Andrey Chernov wrote:
> On Mon, Oct 18, 2004 at 01:23:47PM +0400, Andrey Chernov wrote:
> > In theory we can switch to another *curses, or make termcap as separate 
> > library (even derived from ncurses, subset) to save lots of static linking 
> > space.
> 
Having a separate libtermcap library won't save anything with static
linkage as long as it's a subset of libncurses.  Ideally, the binary
linked with the real termcap library which is a subset of the ncurses
library will even be of the same checksum.

> > In all such cases in my variant we don't need to touch anything, 
> > but in yours mass Makefiles rewriting required.
> 
> In other words: libraries and applications are linked to termcap, without 
> knowing its implementation details. It is good, because things can be 
> changed on the fly without any editing. But you insist that they MUST know 
> implementation details. I see no reason for it.
> 
It's simple.  There's no termcap library, whether you specify -lncurses
or -ltermcap doesn't matter, libraries and applications linked with
either of them all get libncurses.so as their runtime dependency: run
ldd(1) and get it.  ;)

In other words: if you make a real libtermcap today (as a subset of
libncurses), you cannot expect old dynamically linked binaries to
magically start using it, because they have libncurses.so recorded
as their dependency.

The difference between us is how we treat the libtermcap symlinks.
I treat them as compatibility stuff only for third-party applications
that are not part of the standard FreeBSD distribution, and you seem
to treat them as different API libraries.  I also fail to get your
point about why linking with -lncurses as opposed to with -ltermcap
is unportable.

I have a simple question for you: in your opinion, what's wrong with
replacing all these -l{curses,mytinfo,termcap,termlib,tinfo} with
one true -lncurses?  I planned doing it one day, but you seem to be
against it, as follows from the above.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20041018/b91b42ed/attachment.bin