Re: function-local variables in ltmain

[Gary V. Vaughan]

Hi Albert,

Albert Chin wrote:
> On Tue, Aug 16, 2005 at 12:29:13PM +0100, Gary V. Vaughan wrote:
>
> > > > Just seems to make libtool harder to maintain.
> >
> > Au contraire.  Once any such mechanism has been debugged, it makes 
> > libtool easier to maintain... as has been the case with several of the 
> > refactorings I've done as we progress towards 2.0.
>
>
> But debugging libtool occurs with the _generated_ "libtool" script.
> Making the output sane should help debugging, not hinder it. Is this
> so much of a problem that we need such a big hammer to solve it? I
> don't recall seeing enough PRs to consider it.

A good point :-/

I guess that because I have a lisp background, enhancing the language to 
express the problem more clearly seems more natural to me than people 
used to imperative languages.  I still think that as we factor libtool 
into more functions, the single global namespace is a nightmare waiting 
to happen, and we definitely need to come up with a systematic way of 
avoiding these issues before they bite us.

At the moment, I've been able to use the my_ prefix for pseudo-local 
vars, providing that I'm very careful to check the call graphs for 
duplicates to avoid overwriting.  Manually using a $0_ prefix is one 
option, but requires equal care with eval's (as Ralf pointed out), and 
makes refactoring painful, since all the migrated locals need to be 
manually renamed.  Manually saving and restoring globals is a little 
safer, but requires some care with matching saves and restores at each 
stack frame.  Having m4 generate the saves and restores, and automate 
the name generation to prevent clashes without call graph analysis, or 
manual renaming during refactoring would certainly make life even 
easier... at least until debug time, as you point out.

Another option would be to require a shell that provides some minimal 
local variable mechanism, and use that directly.  I'm worried that this 
makes the barrier for use of libtool on some of the commercial unices 
painful -- "if libtool isn't working for you, please install bash first".

We might be able to mitigate the "install bash" problem by using 
Autoconf's shell features hooks to search the system for a shell that 
has local variable support.

What is your (and other libtool users') preferred approach?

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature