automake-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Automake-commit] [SCM] GNU Automake branch, experimental/ng/suffix-simp


From: Stefano Lattarini
Subject: [Automake-commit] [SCM] GNU Automake branch, experimental/ng/suffix-simplify, created. v1.12-288-g1908e70
Date: Thu, 24 May 2012 07:38:42 +0000

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=1908e701fa761a03786a19269ce501819073c364

The branch, experimental/ng/suffix-simplify has been created
        at  1908e701fa761a03786a19269ce501819073c364 (commit)

- Log -----------------------------------------------------------------
commit 1908e701fa761a03786a19269ce501819073c364
Author: Stefano Lattarini <address@hidden>
Date:   Thu May 24 00:10:53 2012 +0200

    [ng] rule, lang: get rid of 'suffix_rules_count', simplify logic
    
    Apparently, some of our pre-existing logic used to determine when we need
    to bring C-related stuff into the generated Makefile was too strict; we can
    simplify it a bit, still keeping the testsuite clean.
    
    * automake.in (handle_languages): Bring in C stuff only if we've seen a
    non-pure language (like yacc or vala) or if '$need_link' is true, without
    bothering to check whether we've seen more than one suffix rules.  This
    change removes the only caller in the automake code base of ...
    * lib/Automake/Rule.pm (suffix_rules_count): ... this subroutine, which
    has thus been removed.
    (@EXPORT): Adjust.
    
    Signed-off-by: Stefano Lattarini <address@hidden>

commit 51caa48a7474f64882cbcebd476980b5559aa908
Author: Stefano Lattarini <address@hidden>
Date:   Wed May 23 23:34:50 2012 +0200

    [ng] coverage: mixing Fortran and C++
    
    * t/cxx-fortran.sh: New, check that Automake can build and link a program
    mixing C++ with Fortran 77 (the C++ 'main()' calling a Fortran function,
    more precisely).
    
    Signed-off-by: Stefano Lattarini <address@hidden>

commit a4c439444a29f62ef21d24d3cbf676919ad1e426
Author: Stefano Lattarini <address@hidden>
Date:   Wed May 23 23:12:47 2012 +0200

    [ng] coverage: pure languages doesn't bring in C support
    
    Automake, when dealing with a Makefile.am using a single "pure" language
    (like C++ and Fortran), shouldn't output stuff related to C compilation.
    Extend some tests checking this behaviour, since it is implemented by a
    parts of the codebase we plan to touch soon.
    
    * t/fnoc.sh, t/cxxnoc.sh: Removed, merged ...
    * t/no-c.tap: ... in here.  Checks for more languages (Java, modern
    Fortran, Objective C and Objective C++).
    * t/suffix3.sh: Enhance.
    
    Signed-off-by: Stefano Lattarini <address@hidden>

commit 15534af1cf51ab8d9bfcd1effddb84f04094b8ff
Author: Stefano Lattarini <address@hidden>
Date:   Wed May 23 13:31:15 2012 +0200

    [ng] rule: get rid of $KNOWN_EXTENSIONS_PATTERN
    
    Another removal of some Automake-time processing.
    
    * automake.in (handle_single_transform): When breaking up the path of a
    source file into (directory, base, extension) components, accept any
    "dotted" extensions (e.g., '.c' and '.y', but also '.foo' and '._'), not
    just the extensions once registered in $KNOWN_EXTENSIONS_PATTERN.
    (register_language): Don't call '&accept_extensions' anymore on the
    extensions of the language being processed (e.g., '.c' for the C language,
    and '.cc', '.c++', '.cxx' and '.cpp' for the C++ language); that was done
    only so that $KNOWN_EXTENSIONS_PATTERN could be properly updated, and that
    variable is obsolete now.
    * lib/Automake/Rule.pm (accept_extensions, $KNOWN_EXTENSIONS_PATTERN):
    Delete these exported subroutine and variable, and their documentation.
    (@EXPORT): Update not to export them anymore.
    (@_known_extensions_list): Remove this internal variable.
    (define): Don't call '&accept_extensions' anymore on the source suffix;
    that was done only so that $KNOWN_EXTENSIONS_PATTERN could be properly
    updated, and that variable is obsolete now.
    
    Signed-off-by: Stefano Lattarini <address@hidden>

commit 09a19a1a9cc0f0f65a4463ed3aefcdcf3875002e
Author: Stefano Lattarini <address@hidden>
Date:   Wed May 23 12:06:39 2012 +0200

    [ng] coverage: custom pre-processes headers in prog_SOURCES
    
    If we specify "foo.my-h" in a prog_SOURCES variable, and then define a
    pattern rule to turn a '.my-h' file in a valid '.h' C header file, things
    should work out smoothly and as expected (as long as we use BUILT_SOURCES
    properly).
    
    * t/suffix-hdr.sh: New test.
    
    Signed-off-by: Stefano Lattarini <address@hidden>

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


hooks/post-receive
-- 
GNU Automake



reply via email to

[Prev in Thread] Current Thread [Next in Thread]