Re: FYI: 6/ Automake::Variable & Automake::VarDef

[Raja R Harinath]

Hi,

Alexandre Duret-Lutz <address@hidden> writes:

> Hi Raja,
>
> (BTW, is Raja your first name, or is it Harinath?  I'm confused
> because you sign 'Hari'.)

Well, "Raja" is my first name in that it appears first in my name :-)  
My given name is Harinath, "Hari" for short.

>>>> "Raja" == Raja R Harinath <address@hidden> writes:
>
> [...]
>
>  Raja> A few comments:
>
> Great!  Thanks for doing that.
>
>  Raja> [snip]
>  >> Index: lib/Automake/Variable.pm
>  Raja> [snip]
>  >> +sub reset ()
>  >> +{
>  >> +  %_variable_dict = ();
>  >> +  %_appendvar = ();
>  >> +  @_var_order = ();
>  >> +}
>
>  Raja> I think this should reset %_hooks too.
>
> Hmmm.  Right now we register hooks (or should I say "the hook"?)
> once for all during Automake's startup.  Clearing %_hooks here
> means we must register them again for each Makefile, although
> they will not change.  I'm not convinced this is better, but I'm
> not sure this is really what you suggest either.

OK.  I think I misunderstood what _hooks were used for.  I thought it
would be attached on a per-Makefile basis.

>  Raja> [snip]
>  >> +sub variable_defined ($;$)
>
>  Raja> I think this belongs back to 'automake.in'.  That'd be the right
>  Raja> place to encode the information about Automake::Rule, when you add it.
>
>  >> +sub variable_assert ($$)
>  >> +sub examine_variable ($)
>  >> +sub require_variables ($$$@)
>  >> +sub require_variables_for_variable ($$@)
>  >> +sub variable_value ($)
>  >> +sub variable_value_as_list($$;$)
>
>  Raja> I think these belong to automake.in, too.  They don't
>  Raja> seem to fit the mold.  It's a tossup, but I think these
>  Raja> are more peculiar to the way Automake uses the variables,
>  Raja> than about implementing the variables.  That's not really
>  Raja> a distinction :-), but ...
>
> I think at some point I moved one of these function to Variable,
> and it pulled all the others :) But I'm not satisfied with
> having these there either.  Some of them, like variable_value
> and variable_value_as_list, could easily be rewritten and used
> as methods.  

You'll also need the _recursive variants in there for consistency.  I
think a separate Automake::Evaluate is warranted ("evaluate" as in
find the value) or Automake::Expand.

> The other probably do not belong to Variable.pm because they can
> work on unexisting variables.  While I wrote Variable.pm I had a
> plan to convert these into methods.  The problem is that these
> functions can work on unexisting variables, but you can't call a
> method without a Variable instance.  The idea was to add a new
> lookup operator: `mvar' (for `maybe var') that either return an
> existing variable, or create a new instance *without* registering to
> %_variable_dict.  So you actually can call methods on a kind of
> ghostly variable.  That sounds a bit clumsy.

I don't like that all that much, either.

> How about moving these to a separate package (Automake::VarAux?
> Automake::VarFuncs?  Automake::VarSupport? Automake::VarMisc?)
> that would be a sort of layer on top of Automake::Variable (and
> Automake::Rule once it's there).  I'm not against moving back to
> automake.in, but I'd like to consider other possibilities.  As
> we move more and more things out of automake.in (which I think
> is a good thing), these functions will be needed outside.

(half serious) How about Automake::Automake :-)

Actually, on a second scan, 'require_variables[_for_variable]' seems
well suited where it is.  variable_assert can be removed, since it's
a wrapper for 'require_variables'.  'require_variables' is a "better"
version of 'rvar' -- except for the marking behaviour of
'variable_defined'.  Can we eliminate the use of 'variable_defined'
and just use 'var' in there?  Is it necessary to 'set_seen' on
required variables?

- Hari
-- 
Raja R Harinath ------------------------------ address@hidden