[Automake-commit] [SCM] GNU Automake branch, experimental/ng/memoize-macros, created. v1.12-217-gca7e97d

[Stefano Lattarini]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Automake".

http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=ca7e97d377d8f3af55a7fc87ce362f4ee75faa25

The branch, experimental/ng/memoize-macros has been created
        at  ca7e97d377d8f3af55a7fc87ce362f4ee75faa25 (commit)

- Log -----------------------------------------------------------------
commit ca7e97d377d8f3af55a7fc87ce362f4ee75faa25
Author: Stefano Lattarini <address@hidden>
Date:   Sat May 12 14:03:26 2012 +0200

    memoize: initial implementation
    
    This is a preparatory patch that introduces on-demand memoization through
    the use of the new internal 'XXX' make function.  Rationale and a
    more detailed explanation follow.
    
    In GNU make as well as in portable make, "lazy-expansion" variables (the
    default kind, deriving from assignments like "var = value") have their
    value recomputed every time they are expanded.
    
    Most of the time, this has no actual impact on performance, since the
    values of lazy variables are usually either static:
    
        prefix = /usr/local
    
    or only contain references to other lazy variables with static contents:
    
        datadir = ${datarootdir}
        datarootdir = ${prefix}/share
    
    In other case, though, the expansion of the value might require some
    non-trivial calculation, or other time-costly operation:
    
        TESTS = $(sort LONG-LIST-OF-FILES)
        VC-VERSION = $(shell git describe)
    
    "Immediate" variables (deriving from assignments like "var = value")
    are better in this respect, since their definition evaluates the LHS
    immediately, and only once.  But alas, this also means they are overly
    sensitive to ordering, in that any variable referenced in the LHS must
    be completely defined before the definition of the immediate variable
    it appears in; and ensuring this might be tricky in general, and even
    more so with Automake, which performs non-trivial reordering of make
    variable.
    
    So, to allow for few optimizations without requiring too much work,
    we go for good middle ground solutions: we implement memoization for
    lazy-evaluations variable which are expected to be expanded often.
    Referencing again the examples above, we would now write something
    like:
    
      am--mm/TESTS = $(sort LONG-LIST-OF-FILES)
      am--mm/VC-VERSION = $(shell git describe)
      $(call am__memoized_variable, TESTS)
      $(call am__memoized_variable, VC-VERSION)
    
    This API is a little more verbose and clumsy than we'd like, but all
    the other "more obvious" attempts ended up causing "recursive variable
    references itself (eventually)" kind of errors, or misbehaving when
    the definition's LHS was very long.  And anyway, it's just an internal
    experimental API, se we can change it at a later time if we find a
    better implementation.
    
    From a suggestion by Akim Demaille:
    <http://lists.gnu.org/archive/html/automake-ng/2012-05/msg00062.html>
    
    * lib/am/header-vars.am (am__memoized_variable): New internal function.
    (am__memoized_variable_0): Likewise.
    * t/spy-override.sh: New test, check that we can use the 'override'
    directive as we do in the 'am__memoized_variable' implementation.
    * t/memoize.tap: Likewise.
    
    Signed-off-by: Stefano Lattarini <address@hidden>

-----------------------------------------------------------------------


hooks/post-receive
-- 
GNU Automake