Re: [PATCH] Enable building GDB without installed libtermcap

[Pedro Alves <palves@redhat.com>]

Moving to gdb-patches@sourceware.org.  Please keep replies there.

On 02/22/2015 03:11 AM, Bernd Edlinger wrote:
>           Hi,
> 
> currently building gdb is impossible without an installed termcap or a curses library.
> That can be rather aw-quad when building a gdb for a build != host configuration.

Hmm, but how is that different from any other dependency?

> The idea for this patch is to include a simple version of libtermcap as a fall-back
> for the case that the host compiler does not have any cursor library.  This enables
> at least a non tui-enabled gdb.  It works even if there is no termcap configuration
> file on the target.  If a termcap or curses library can be found when configuring gdb,
> we will use the installed library instead of the included libtermcap.
> 
> I used the latest available GNU libtermcap-1.3.1 from http://ftp.gnu.org/gnu/termcap/,
> refreshed the autoconf files and integrated that in the gdb build system.

I don't see any change to libtermcap that makes this a "simple version of libtermcap".
AFAICS, this is really libtermcap, minus the manual and the definitions.  Parts of
the libtermcap patch you show look like something that really should be sent
to libtermcap's list, even.

> I verified that this patch builds various cross-configurations, including target=cygwin.
> 
> To keep the patch files below the limit of 400K for this newsgroup, the attached patch
> assumes that termcap-1.3.1 is first copied to the folder binutils-gdb/libtermcap.
> The texinfo files termcap.info.* need to be manually deleted, as they can be regenerated.
> Then the patch file patch-libtermcap.diff needs to be applied on the libtermcap folder,
> and then autoconf 2.64 needs to be done on the libtermcap folder. Finally the
> patch file patch-gdb-termcap.diff needs to be applied on the binutils-gdb folder.
> 
> 
> OK for trunk?

Sorry, without a better rationale, I don't see how this makes sense.  We
like to have _fewer_ copies of upstream projects in the repo (such as
e.g., readline), not more.

Thanks,
Pedro Alves