This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/8] Upgrade readline


On Wednesday, August 07 2019, Tom Tromey wrote:

>>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:
>
> Sergio> I'm in favour of bumping the readline version to 7 (note that Debian
> Sergio> oldstable, i.e., wheezy, which was released 4+ years ago, already ships
> Sergio> with readline 7), and (eventually) just get rid of our local copy.
>
> We talked about that briefly on irc yesterday too.

Yes (for a different value of "yesterday" now).

> I wonder if we really could get rid of the local copy.  I mean,
> obviously we could, but would it be a problem for anybody?

[ /me puts his downstream hat ]

I guess it depends.  If the person is building GDB on a system that
doesn't offer readline-dev or a similar package, then it can be a
"problem" in the sense that he or she will have to compile readline by
hand, probably.

Otherwise, I don't see how it can be a problem.  As I pointed out during
the IRC discussion, the two major GNU distros (Fedora and Debian) are
already compiling their GDB packages using --with-system-readline, so,
in a way, our readline copy is not needed.  These distros also provide
readline-dev, which makes it very easy for users to compile their own
GDBs without using our local readline copy.

OOC, I went to check how Arch[GNU/]Linux compiles GDB, and they are also
using --with-system-readline.

> We could treat it a few ways.  One would be like libiconv: keep the
> top-level configury around so it's possible to drop the readline sources
> into the tree and then build.

That'd be a good compromise, IMO.

> Another way would be to use something like guix for these dependencies.
> I don't know if that works on all the hosts that we care about.
>
> The guix way is attractive since it seems vaguely analogous to using
> "cargo" in the Rust world.  In particular if we could do something like
> this, maybe we could be less conservative about bringing in new
> dependencies.

The guix idea seems awesome, but that's because I like guix ;-).  If I'm
honest, I don't like the idea of keeping readline in-tree at all; I'd
prefer to have guix manage some "obscure" dependency that can be missing
in some system.  But that's me and my "let's not turn everything into a
flatpak" feeling ;-).

> I think either of these solutions would also fix the bug we found with
> moving gdbsupport to the top level (i.e. that it interacts poorly with
> --with-system-readline).  (I never got a response to that note, so if
> you're reading this, I'd appreciate a quick look at that as well.)

I'll take a look, thanks for mentioning!

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]