Re: Removal of libtool1.4
Scripsit Warren Turkal <wt@midsouth.rr.com>
> Henning Makholm wrote:
> > Scripsit Scott James Remnant <scott@netsplit.com>
> >> 3) It is only required when used with Autoconf 2.13, which is also no
> >> longer maintained upstream.
> > This worries me a bit. Some upstream authors refuse to use autoconf
> > 2.5x on general principles - could dropping libtool1.4 support mean
> > that certain bugs in their packages can only be fixed if one *also*
> > ports their configure.in to 2.5x and keeps that port seperately
> > maintained forever after?
> What "general principles"?
Some arguments are given on
<http://www.invisible-island.net/autoconf/autoconf.html>. I hasten to
add that these are not *my* arguments, and I haven't even tried to
decide whether I think they are valid or not. But it is clear that
this particular upstream author would reject a patch that upgraded his
configure.in to 2.5x. I assume that there are other authors out there
who feel like him.
(Xterm itself needing 2.13 would not be a problem for Debian, because
it also comes witn an Imakefile, and I think Branden uses the latter
for building the xterm package, ignoring the configure script).
> If you have actually gotten xterm working with a modern version of
> autoconf, please contribute these changes to freedesktop.org.
Actually, I ruthlessly removed a lot of the configuration options.
(My goal for that particular exercise was to produce an xterm derivate
with a more predictable behavior than xterm itself, so most of the
options I just hardwired to "no"). It is not clear to me that I would
have succeeded if my goal had been to reproduce the current upstream
configure script's behavior, but using autoconf 2.5x.
--
Henning Makholm "It was intended to compile from some approximation to
the M-notation, but the M-notation was never fully defined,
because representing LISP functions by LISP lists became the
dominant programming language when the interpreter later became available."
Reply to: