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

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: