Re: [shell functions, was RE: solving of name conflicts in included . a]

[Charles Wilson]

Bob Friesenhahn wrote:


> > "Shall libtool-1.5 require autoconf-2.56?"
>
> I don't see that introducing shell functions into libtool has any
> bearing on the version of autoconf that libtool requires.
>
> The argument you pose is political rather than technical.


Yes.  The decision itself is a political one.  "Shall libtool (and 
autoconf) continue to support museum pieces?"  I was just posing the 
question in a different way -- trying to make the point (poorly, 
apparently) that the decision has already been made for us.

I really should've said "Shall libtool-1.5 be forever frozen at autoconf 
versions < 2.56" which is not quite the same thing.  And of course, the 
answer to that question is no.


> The only question that needs answering is if using shell functions
> will hurt libtool users, or if it will help libtool users.


There's a novel concept. :-)


> Libtool's configure script is a wopping 584K.  The configure script
> for ImageMagick is 1.1M, about half of which may be blamed on libtool.
> It is not uncommon these days to find packages where the configure
> script dwarfs the rest of the package.  If shell functions can allow
> configure scripts which are 1/10th the size, and run 5X as fast, then
> perhaps that should take precedence over the ability to run libtool on
> a V7 system in a museum.


Well, I like shell functions.  And I think this whole decsion has been 
taken out the libtool-maintainers' hands, given the decision of the 
autoconf team.

Since autoconf (>= 2.56) will only work on systems whose shells support 
shell functions, and libtool requires autoconf, then libtool will only 
work on those same systems.  Which means shell functions are available 
and we *can* use them.  Whether we *should* use them or not is then a 
technical decision, resting on the arguments you put forward above.

--Chuck