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

[Alexandre Duret-Lutz]

>>> "Hari" == Raja R Harinath <address@hidden> writes:

[...]

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

Ok, thanks for explaining.

[...]

 >> Some of them, like variable_value and
 >> variable_value_as_list, could easily be rewritten and used
 >> as methods.

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

I was planning to define all of these as Variable methods :(
After all, these are all about asking a variable for its value
(variable_value_as_list_recursive) or iterating over the
variable's contents (traverse/transform_variable_recursively).
Doesn't the following invocation sound natural?

  $var->value_as_list_recursive ($cond);
  $var->traverse_recursively ($fun_item, $fun_collect, $cond_filter);
  $var->transform_recursively ($res, $base, $nodef, $where, $fun_item);

[...]

 Hari> Actually, on a second scan, 'require_variables[_for_variable]' seems
 Hari> well suited where it is.  

Raahh.  These were the function I found the most misplaced.  They
are not used by any other functions in Variable.pm, and 
require hard-coded knowledge such as %_am_macro_for_var and 
%_ac_macro_for_var which I think have nothing to do in Variable.pm
(although it's obviously hard to draw a line).

 Hari> variable_assert can be removed, since it's a wrapper for
 Hari> 'require_variables'.  

done

 Hari> 'require_variables' is a "better" version of 'rvar' --
 Hari> except for the marking behaviour of 'variable_defined'.

Hmm.  Not quite.  I should probably improve the documentation in
some way.  Both functions indeed require variables, but when the
variable is missing the guilty is different.

require_variables is used in places where Automake expects the
user to have defined some variable (e.g., PYTHON should be
defined if you use python_PYTHON).  When the variable doesn't
exist, the user gets a diagnostic such as "python_PYTHON used
but PYTHON not defined, the usual means to define PYTHON is
AM_PATH_PYTHON".

rvar is used in places where it would be an Automake bug that
the variable is not defined.  The user is not at fault: the
programmer is.  Typically, evaluating var ('foo')->method
assumes that 'foo' has been defined, otherwise Perl will
complain it can't call ->method on.  This assumption is better
made explicit with rvar ('foo')->method.  If 'foo' doesn't
exist, Automake will print a full stack-trace with instructions
to send a bug-report.  This is more helpful than Perl's
single-line diagnostic.

 Hari> Can we eliminate the use of 'variable_defined' and just
 Hari> use 'var' in there?  

Yes, that sounds sensible.

Perhaps it would also be a good reason to drop the
"rule-vs-variable" diagnostic (which is currently commented out
in variable_defined).  This diagnostics only causes
implementations issues, and I suspect it doesn't help anybody.

 Hari> Is it necessary to 'set_seen' on required variables?

I don't know.  I think it's only important for the variables
looked up by check_typos().  It shouldn't hurt, though.

BTW, since patch 6/ these 'seen' bits are stored on a
per-condition basis.  Before that they were only defined on a
per-variable basis.
-- 
Alexandre Duret-Lutz