[Automake-commit] [SCM] GNU Automake branch, experimental/ng/suffix-rules-mutilation, created. v1.12-331-g842d182

[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=842d182c42e17aa9f01617e750b2fad05d98ea27

The branch, experimental/ng/suffix-rules-mutilation has been created
        at  842d182c42e17aa9f01617e750b2fad05d98ea27 (commit)

- Log -----------------------------------------------------------------
commit 842d182c42e17aa9f01617e750b2fad05d98ea27
Author: Stefano Lattarini <address@hidden>
Date:   Sat May 26 11:39:29 2012 +0200

    suffix: remove Automake-time chaining of suffix rules
    
    This change simplifies the Automake::Rule module a little, moves yet
    more logic from Automake runtime to GNU make runtime (in the spirit of
    Automake-NG), and gets us rid of some never-documented nor completely
    specified Automake magics.  OTOH, it also breaks some idioms that, while
    only relevant for uncommon cases, have been working since the first
    Automake releases.  Still, it is easy to slightly modify those idioms to
    have the use cases they were catering to correctly handled with the new
    semantics (examples of this are given below); the only downside being the
    need of a little more verbosity and explicitness on the user's part.
    
    So, with the present change, automake starts using a much simpler and
    dumber algorithm to determine how to build an object associated to a
    source whose extension in not one of those it handles internally.
    
    The new algorithm goes like this.  For any file listed in a '_SOURCES'
    variable whose suffix is not recognized internally by automake (in
    contrast to known suffixes like '.c' or '.f90'), automake will obtain
    the expected target object file by stripping the suffix from the source
    file, and appending either '.$(OBJEXT)' or '.lo' to it (which one depends
    on whether the object is built as part of a program, a static library, or
    a libtool library).  It will then be assumed (but not checked!) that the
    user has defined a rule (either explicit or defined from a pattern rule)
    which can turn that source file into this corresponding object file.  For
    example, on an input like:
    
          bin_PROGRAMS = foo
          foo_SOURCES = mu.ext1 fu.ext1 zu.ext1
    
    automake will expect that the three objects 'mu.$(OBJEXT)', 'fu.$(OBJEXT)'
    and 'zu.$(OBJEXT)' are to be used in the linking of the 'foo' program, and
    that the user has provided proper recipes for all those objects to be
    built at make time, as well as a link command for linking 'foo'.  Here is
    an example of how those declarations could look like:
    
        %.$(OBJEXT): %.ext1
                my-compiler -c -o $@ $<
        # We need to compile mu with debugging enabled.
        mu.$(OBJEXT): mu.ext1
                my-compiler -DDEBUG=1 -c -o $@ $<
        foo_LINK = $(CC) -o $@
    
    In this particular case, the idiom above is basically the same one that
    would be required in mainline automake (apart for the fact that, there,
    old-fashioned suffix rules should be used instead of pattern rules).  To
    see what is truly changed with the new algorithm, we have to look at a
    more indirect usage.
    
    Mailine Automake used to follow the chain of user-defined pattern rules
    to determine how to build the object file deriving from a source file
    with a custom user extension; for example, upon reading:
    
         %.cc: %.zoo:
                 $(preprocess) $< > $@
         bin_PROGRAMS = foo
         foo_SOURCES = bar.zoo
    
    automake knew that it has to bring in the C++ support (compilation rules,
    requirement for AC_PROG_CXX in configure.ac, etc), and use the C++ linker
    to link the 'foo' executable.
    
    But after the present change, automake *won't follow those implicit
    chains of pattern rules* anymore; so that the idiom above will have to
    be re-worked like follows to preserve its intent and behaviour:
    
         %.cc: %.zoo:
                 $(preprocess) $< > $@
         bin_PROGRAMS = foo
         # The use of '.cc' is required to let Automake know to bring in
         # stuff for the handling of C++ compilation, and to use the C++
         # linker to build 'foo'.
         nodist_foo_SOURCES = bar.cc
         EXTRA_DIST = foo.zoo
    
    Finally, we must note another, slightly annoying first consequence of
    this change of semantics: one can't use anymore "header files" with
    extensions unrecognized to Automake anymore; for example, an usage like
    this:
    
        # Won't work anymore: will cause errors at make runtime.
        %.h: %.my-hdr
              $(preprocess-header) $< >$@
        foo_SOURCES = foo.c bar.my-hdr
        BUILT_SOURCES = bar.h
    
    will cause the generated Makefile to die on "make all", with an error
    like:
    
        make[1]: *** No rule to make target 'bar.o', needed by 'zardoz'.  Stop.
    
    while an usage like this:
    
        # Won't work anymore: will cause errors at automake runtime.
        %.h: %.my-hdr
              $(preprocess-header) $< >$@
        foo_SOURCES = foo.c foo.my-hdr
        BUILT_SOURCES = foo.h
    
    will cause automake itself to die, reporting an error like:
    
        object 'foo.$(OBJEXT)' created by 'foo.my-hdr' and 'foo.c'
    
    We don't believe the above breakage is a real issue though, because
    the use case can still be served by placing the "non standard" headers
    in EXTRA_DIST rather than in a _SOURCES variable:
    
        # This will work.
        %.h: %.my-hdr
              $(preprocess-header) $< >$@
        foo_SOURCES = foo.c
        EXTRA_DIST = foo.my-hdr
        BUILT_SOURCES = foo.h
    
    A more detailed list of changes follow ...
    
    * automake.in (register_language): Don't call 'register_suffix_rule'
    on the source and object extensions of the registered languages.
    (handle_single_transform): Implement the new simple algorithm described
    in details above (plus an hack to continue supporting Vala-related
    '.vapi' files in _SOURCES variables).  Remove the only call ever to ...
    (derive_suffix): ... this function, which has thus been removed.
    * lib/Automake/Rule.pm
    ($_suffix_rules_default, $suffix_rules, register_suffix_rule): Remove.
    (@EXPORT, reset): Adjust.
    (define): Don't call 'register_suffix_rule' on the suffixes of target
    and dependency when a pattern rule is seen.
    * t/specflg10.sh: Move ...
    * t/am-default-source-ext.sh: ... to this more proper name, and
    adjusted.
    * t/suffix12.sh: Renamed ...
    * t/suffix-custom-subobj.sh: ... to this, and remove a botched heading
    comment.
    * t/suffix3.sh: Adjust.
    * t/suffix5.sh: Likewise.
    * t/suffix8.sh: Likewise.
    * t/suffix10.sh: Likewise.
    * t/suffix13.sh: Likewise.
    * t/suffix-chain.sh: Likewise.
    * t/suffix-hdr.sh: Likewise.
    * t/suffix-custom.sh: New test.
    * t/suffix-custom-link.sh: Likewise.
    * t/suffix-custom-default-ext.sh: Likewise.
    * t/yacc-lex-cxx-alone.sh: Likewise.
    
    Signed-off-by: Stefano Lattarini <address@hidden>

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


hooks/post-receive
-- 
GNU Automake