Re: [bug-gnu-libiconv] [PATCH 0/1] drop out versions from autotools programs

[Bruno Haible]

Hi Petr,

> > > Looks that requirement of precise versions of autotools
> > > is too strong. It is fine for other versions too.  
> > 
> > Yes, but adding the version suffix makes sure I and you use an
> > up-to-date automake version, and I don't mistakenly make a release
> > with an outdated automake version (like I already did a release with
> > an outdated gperf version).
> 
> Hmm, and drop out newer autotools, that _not install_
> autoconf-{version}/autoheader-{version}.

Older autoconf versions don't install this either. I forgot to mention
this in the HACKING file:
https://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=commitdiff;h=cd1a56c391b082ec813206bb0da5e30066e63c2b

> > > ltmain.sh will come from autotools, no needs to keep it here,
> > > autotools will re-write it.  
> > 
> > No, this is wrong for two reasons:
> >   - libtool.m4 would not be found if automake was installed with a
> >     different --prefix than libtool.
> 
> Installation of automake is a problem of installation automake, IMO.

Possibly. But I want that people have the freedom to install modified
versions of automake without also installing libtool, and vice versa.

> >   - We need a patched libtool, see
> >     
> > https://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=commitdiff;h=b12cf8e93bc39f10bc134004de45d5f4a1ec9bac
> 
> libtool will owerwrite it in any case.
> ...
>   root@void-ptr# libtoolize

The HACKING file does not tell you to invoke 'libtoolize'. It tells
you to invoke './autogen.sh', and this recipe does NOT invoke libtoolize.

Bruno