[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 13:38:40 +0200 |
User-agent: |
Mutt/1.4.1i |
Hi Gary,
Welcome back!
* Gary V. Vaughan wrote on Tue, Aug 16, 2005 at 01:29:13PM CEST:
> Ralf Wildenhues wrote:
> >* Albert Chin wrote on Sat, Aug 13, 2005 at 09:56:43PM CEST:
> >>On Sat, Aug 13, 2005 at 10:40:01AM +0200, Ralf Wildenhues wrote:
>
> >Just look at two examples: func_extract_archives uses variables named
> >my_*. This is not safe: both its caller and any functions it may call
> >itself may overwrite these accidentally. func_extract_an_archive OTOH
> >uses safe names f_ex_an_ar_*, but is ugly to the point of being
> >unreadable.
>
> 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.
We might be able to cope with this limitation. But it's a limitation
that
- "real" local variables do not have
- my solution does not have
- seems artifical to some point, and dangerous to another: in the m4sh
source file, this might easily be overlooked!
> On the principle of looking at the .m4sh files way more often than the
> generated libtool script, I don't think it is worth the trouble.
>
> >I do _not_ want to eliminate use of globals. All I want is an easier
> >method for ensuring this than regular grepping of the whole script.
> >I'm certainly not determined to use this particular idea.
>
> I am :-) Eventually.
No, please don't. I have been sending small patches which change only
one thing at a time on purpose. No need to over-engineer anything here.
> In my copious free time ;-)
Ahh, yes, ok, now I know how you meant that. :->
Cheers,
Ralf