bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opening a can of worms: a readline gnulib module?


From: Simon Josefsson
Subject: Re: Opening a can of worms: a readline gnulib module?
Date: Sat, 16 Jul 2005 10:53:45 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> Do you think a "readline" module such as the above would be a
>> candidate for gnulib?
>
> For application that only use this main entrypoint, yes. But other
> applications need to customize the library's behaviour
> (rl_basic_word_break_characters, rl_basic_quote_characters,
> rl_completer_quote_characters, rl_completion_entry_function,
> rl_readline_name, calls to rl_add_defun etc.). Do you want to provide
> all these symbols?

No.  If they are needed, a gnulib module of the entire readline
library appear more appropriate.

>> Alternatively, how about packaging the entire readline library as a
>> gnulib module?  It is about 20kloc, but some of it appear to already
>> be part of gnulib, e.g., xmalloc.  I haven't dared to look at the code
>> quality.
>
> That library weighs 175 KB of binary code. Its source is ANSI C, meanwhile.
> The bigger problem with having it in gnulib is that its maintainer does
> not favour open/collaborative development.

Then a short readline replacement like my code may be all we can do
for now.

> Also, having it in gnulib would mean that the code would reside in
> several packages and could be linked statically into several applications
> - which is contrary to the benefits that shared libraries bring (namely
> 1. don't waste RAM, 2. ability to upgrade the library without relinking the
> programs).

But the gnulib code wouldn't be used if the library was available?  I
see it as making sure my package always build, regardless of what is
installed on the target system.  If readline isn't available, I find
it annoying to abort building and ask the user to install readline,
especially when 10 loc can fix it.

And doesn't the same argument apply to much of what's in gnulib
already?  It seems many modules in gnulib is shared between many
tools, coreutils, findutils, etc, which thus waste RAM (same code
loaded by several tools), and further, will require new releases of
all those packages when a security bug is found in a gnulib module.

All of this is hypothetical though, since it doesn't look like adding
the readline library as a gnulib module will happen now.

Thanks,
Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]