[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: function-local variables in ltmain
From: |
Ralf Wildenhues |
Subject: |
Re: function-local variables in ltmain |
Date: |
Tue, 16 Aug 2005 16:33:02 +0200 |
User-agent: |
Mutt/1.4.1i |
Hi Gary,
* Gary V. Vaughan wrote on Tue, Aug 16, 2005 at 04:06:38PM CEST:
> Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Tue, Aug 16, 2005 at 01:29:13PM CEST:
> >>
> >>maintain an m4 map of function name to enumeration encoding, and name
> >>the local variables localxx_var_name if output ugliness is a big issue.
> >
> >This breaks `eval'. For the above-mentioned functions, that is no
> >issue. But it prevents us from using any TAGVARs within such a function
> >with local variables, for example.
>
> I don't see how... everything would be identical to your solution,
> except that instead of prepended the function name to m4 local vars, we
> could name them with a prefix of localxx (where xx is some enumeration
> guaranteed to be unique by tracking the mapping in an m4 array) for
> readability.
func_create_old_archive ()
{
# for some reason (e.g. "interesting" archivers like `link -lib')
# we need to adapt old_deplibs, which is _LT_TAGVAR'ed.
local(old_deplibs, ...)
#...
func_execute_cmds "$old_archive_cmds" # this uses `eval'
#...
endfunc
}
Now if I understand your proposal correctly, that just won't work then.
Clear now?
> >We might be able to cope with this limitation. But it's a limitation
> >that
> >- "real" local variables do not have
>
> ACK. Maybe we could collaborate with the autoconf guys to hook into the
> new FEATURES interface to search for a shell that has real local variables?
Maybe.
Cheers,
Ralf