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

[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=88289c17bfc6fefcecc667b21780228f923ac2e3

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

- Log -----------------------------------------------------------------
commit 88289c17bfc6fefcecc667b21780228f923ac2e3
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 implementation a little, moves yet
    more logic from Automake runtime to GNU make runtime (in the spirit of
    Automake-NG), and it gets us rid of some never documented, not completely
    specified Automake magics.
    
    It also breaks some idioms that, while only relevant for uncommon cases,
    have been working since the first Automake releases.  Still, since it
    easy to slightly modify those idioms to have the use case the catered to
    handled correctly
    
    Status Quo
    ----------
    
      Automake used to follow the chain of user-defined pattern rules to
      determine how to build the object file from a file with custom user
      extensions; for example, upon
    
    Result of the Change
    --------------------
    
      Now, for any file listed in a '_SOURCES' variable whose suffix is not
      recognized internally by automake (as, say, '.c' or '.f90' or '.h++'
      are), it will simply be assumed that the user has defined an explicit or
      a suffix rule which can turn that file into a corresponding object file
      (same basename, but with a '.$(OBJEXT)' suffix if it built as part of a
      program or a static library, and with a '.lo' suffix if it is built as
      part of a libtool library).  For example, on an input like:
    
          bin_PROGRAMS = foo
          lib_LTLIBRARIES = libbar.la
          foo_SOURCES = mu.ext1 fu.ext1
          libbar_la_SOURCES = zap.ext2
    
      automake will expect that the two "plain" objects 'mu.$(OBJEXT)' and
      'fu.$(OBJEXT)' are to be used in the linking of the 'foo' program,
      that the libtool object 'zap.lo' is to be used in the linking of the
      'libbar.la' libtool library, and that the user has provided proper
      declarations for all those objects to be built at make time.  Here
      is an example of how such declarations could look like:
    
          %.$(OBJEXT): %.ext2
                  my-compiler -c -o $@ $<
          %.lo: %.ext2
                  $(LIBTOOL) --mode=compile my-compiler -c -o $@ $<
          # We need to compile mu with debugging enabled.
          mu.$(OBJEXT): mu.ext1
                  my-compiler -DDEBUG=1 -c -o $@ $<
    
      We believe this change is good, for the following reasons, because it 
moves
    yet more logic from Automake runtime to GNU make runtime (in the spirit of
    Automake-NG), and it gets us rid of some never documented, not completely
    specified Automake magics.
    
    First Consequence
    -----------------
    
    A first consequence of this change of semantics is that one can't use
    "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
    
    Another, more important consequence
    This means that more help and verbosity from the user will be required,
    in case the generation.
    
    Automake is not aware of any implicit chaining
    
    But it also mean we have to perform less magic and less Automake-time
    preprocessing, and doing so is one of the main purposes of Automake-NG.
    
    As a more complex example, usages like this:
    
        %.cc: %.zoo
                $(preprocess-source) $< >$@
        %.h++: %.my-hdr
                $(preprocess-header) $< >$@
        prog_SOURCES = foo.zoo bar.cc baz.h++
        BUILT_SOURCES = baz.h++
    
    should be converted to read something like this now:
    
        XXX
        XXX
    
    Signed-off-by: Stefano Lattarini <address@hidden>

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


hooks/post-receive
-- 
GNU Automake