kc3-lang/automake/NEWS

Branch :

Log

Author Commit Date CI Message
b04ea3e9 2013-12-25 16:44:17 Merge branches 'fix-pr11814' and 'drop-perl-tap-driver' into minor * fix-pr11814: docs: drop a few obsolescent FIXME/TODO comments, and associated text testsuite harness: report test exit status in log file * drop-perl-tap-driver: TAP driver: remove perl implementation (move it into contrib/) Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
c7e2fb2e 2013-12-24 17:45:18 testsuite harness: report test exit status in log file The exit status of a test should be reported in the test logs, so that one can see at a glance whether the test has succeeded or failed, without having to look also into the corresponding .trs file. This fixes automake bug#11814. * lib/test-driver: Also report the test script exit status in the test log (as the last line). * t/check-exit-status-reported.sh: Test this new behaviour. * t/list-of-tests.mk: Add the new test. * t/ax/test-lib.sh( am_exit_trap): No longer log the test exit status; this has been made redundant by the change to 'test-driver'. While at it, fix an imperfect quoting. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
a6d6734f 2013-12-24 16:27:28 TAP driver: remove perl implementation (move it into contrib/) That implementation was only meant as a standard against which the portable awk+shell implementation was to be measured. Now, since Automake 1.12, the latter implementation is fully functional and already used in the wild, and in fact feature-par with the perl implementation. So the perl implementation is now just slowing down and complicating our testsuite. Let's move it to 'contrib/' (we don't want to remove it, in case someone is actually using it in the wild). * lib/tap-driver.pl: Move it ... * contrib/tap-driver.pl: ... here. While at it, convert quoting `like this' to quoting 'like this', and remove an obsolescent FIXME comment. * lib/Makefile.inc (dist_script_DATA): Drop '%D%/tap-driver.pl'. * Makefile.am (EXTRA_DIST): Add 'contrib/tap-driver.pl'. * doc/automake.texi: Remove one stray reference to 'tap-driver.pl', and reference 'tap-driver.sh' instead, as intended. * t/ax/am-test-lib.sh ($am_tap_implementation): Delete definition and uses. (fetch_tap_driver): Simplify to unconditionally assume the shell+awk implementation of the TAP driver is used. (get_shell_script): Make more flexible so that it can cater to the needs of 'fetch_tap_driver()'. * t/tap-bad-prog.tap: Likewise. * t/tap-bailout-leading-space.sh: Likewise. * t/tap-signal.tap: Likewise. * t/tap-test-number-0.sh: Likewise. * t/test-driver-cond.sh: Use 'tap-driver.sh' instead of 'tap-driver.pl'. * gen-testsuite-part (%test_generators): Do not generate sister tests that use the perl TAP driver rather than the shell+awk one. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
526c4b04 2013-12-24 15:28:23 NEWS: stop reporting "new" Automake versioning scheme It's actually old news by now. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
4527bb9a 2013-11-02 02:50:38 Merge branch 'modernize-install-sh' into minor * modernize-install-sh: cosmetics: untabify the install-sh script install-sh: assume that "set -f" and "set +f" work... install-sh: assume ${var:-value} works as expected install-sh: assume 'dirname' is available and working correctly
e5eb95ce 2013-11-01 22:41:23 Merge branches 'fix-pr14991' and 'fix-pr14891' into micro * fix-pr14991: distcheck: don't allow overriding of --prefix and --srcdir by the user tests: expose bug#14991 (relates to 'distcheck') * fix-pr14891: automake: account for perl hash order randomization tests: avoid use of intervals to capitalize letters
52e64045 2013-07-21 17:58:05 automake: account for perl hash order randomization Try to explicitly order the keys of some perl hashes when looping on them to do sanity/correctness checks and possibly display warning messages; this should ensure a more reproducible output. Not really a big deal, but I prefer to keep the order of such output reproducible if possible. Issue revealed by spurious testsuite failures with perl 5.18, as reported in automake bug#14891. See also: <http://search.cpan.org/dist/perl-5.18.0/pod/perldelta.pod#Hash_randomization> <http://onionstand.blogspot.ie/2012/12/are-you-relying-on-hash-keys-being.html> * lib/Automake/Variable.pm (variables): Explicitly order the values of the returned Automake::Variable instances. (variables_dump): Simplify, using the knowledge that 'variables()' now sorts its output. * t/preproc-errmsg.sh: Adjust. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
006ca8d9 2013-10-30 23:17:55 install-sh: assume that "set -f" and "set +f" work... ... and disable/enable shell globbing, respectively. This is mandated by POSIX, and supported even by Solaris 9 /bin/sh (one of the most braindead shells we still support). * lib/install.sh: Adjust. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
bd44db1a 2013-10-30 22:58:16 install-sh: assume ${var:-value} works as expected The Autoconf manual says it is OK these days. * lib/install.sh: Adjust. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
1b61da33 2013-10-30 22:44:34 install-sh: assume 'dirname' is available and working correctly Really, we no longer care about hosts so outdated/broken to miss fundamental utilities like basename or dirname. * lib/install.sh: Adjust. * NEWS, THANKS: Update. Suggested-by: Philipp A. Hartmann <philipp.hartmann@offis.de> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
9b156829 2013-10-30 21:41:39 distcheck: don't allow overriding of --prefix and --srcdir by the user Not through AM_DISTCHECK_FLAGS, nor through DISTCHECK_FLAGS. Apparently, some packages got in the habit of relaying all the options passed to the original ./configure invocation through to the configure invocations in "make distcheck". This was causing problems, because it also passed through the original --srcdir and --prefix options. Fixes: expose bug#14991 (relates to 'distcheck') * lib/am/distdir.am (distcheck): Pass the hard-coded --srcdir and --prefix options *after* both the developer-defined options in $(AM_DISTCHECK_FLAGS) and the user-defined options in $(DISTCHECK_FLAGS). * t/list-of-tests.mk (XFAIL_TESTS): Remove the now-passing test 'distcheck-no-destdist-or-srcdir-override.sh'. * doc/automake.texi (Checking the Distribution): Update. * NEWS: Likewise. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
1e2f142f 2013-10-30 00:04:51 tests: fix spurious failure due to localization issues Fixes automake bug#15237. * t/autohdr-subdir-pr12495.sh: Ensure make is run in the C locale, so that we can expect error messages in English when grepping its output. * THANKS, NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
8a310a5f 2013-10-30 00:51:25 tests: fix spurious failure when zip is present but unzip is not Fixes automake bug#15181. * t/dist-formats.tap (have_compressor): When checking that zip(1), also check for unzip(1), otherwise "make distcheck" will be unable to extract the zip tarball it creates, which will cause spurious failures. While at it, reorganize the existing code a bit. * THANKS, NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
8dbdc495 2013-10-29 23:50:49 NEWS: update with the changes since v1.14 Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
e40a6145 2013-06-27 15:00:10 NEWS: post-release tweaks (for 1.14.x series) Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
873fed9e 2013-06-20 10:29:09 NEWS: one more minor fixlet Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
3f1d7622 2013-06-19 13:22:33 NEWS: improve and update wording Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
6febcd41 2013-06-12 21:22:58 Merge branch 'micro' into maint * micro: THANKS: update e-mall address for Ralf Corsepius lang, suffix rules: don't require C stuff needlessly tests: expose automake bug#14560 Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
4f7cc4fe 2013-06-11 21:20:18 lang, suffix rules: don't require C stuff needlessly This change fixes automake bug#14560: when two or more user-defined suffix rules were present in a single Makefile.am, automake would needlessly include definition of some make variables related to C compilation in the generated Makefile.in. * automake.in (handle_languages): Fix logic to decide whether or not to include definitions of C compilation related variables in the generated Makefile.in: instead of doing so when two or more user-defined suffix rules are seen (which is a completely bogus criterion), do so when two or more compiled languages are used. * lib/Automake/Rule.pm (suffix_rules_count): Remove as no longer used. (@EXPORT): Adjust. * t/list-of-tests.mk (XFAIL_TESTS): No longer list the test script 'suffix-extra-c-stuff-pr14560.sh', which now passes. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
6d03501b 2013-06-03 15:25:50 Merge branch 'micro' into maint * micro: NEWS: minor fixlets, re-wording, and better text wrapping tests: slightly stricter checks in t/cxx-demo.sh tests: fix spurious failure when 'etags' program is Exuberant Ctags tests: fix spurious failure due to missing sleeps
a7cf36ae 2013-06-03 15:12:18 NEWS: minor fixlets, re-wording, and better text wrapping Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
0d9399f1 2013-05-30 11:55:48 Merge branch 'micro' into maint * micro: NEWS: document recent testsuite fixes (MinGW/MSYS related) depcomp: avoid trailing backslash in depfile for depmode=msvc7 tests: prune some weed in a non-POSIX test tests: avoid a spurious failure on MSYS
d3b8ad21 2013-05-30 11:28:02 NEWS: document recent testsuite fixes (MinGW/MSYS related) Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
c98d5235 2013-05-29 10:39:58 Merge branch 'micro' into maint * micro: NEWS: fix typos and grammaros NEWS: document fix for bug#14441 Automake::Rule: consistently prepend underscore to private variables Automake::Rule: rename: suffix_rule() -> next_in_suffix_chain() Automake::Rule: adjust comments and POD according to previous changes Automake::Rule: make private variables lexically scoped suffix rules: better distinction between builtin and user-derived Automake::Rule: expose suffix rules as a function, not a scalar tests: expose automake bug#14441
03025525 2013-05-29 10:20:48 NEWS: fix typos and grammaros Reported-by: Peter Rosin <peda@lysator.liu.se> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
f7540da7 2013-05-28 22:04:25 Merge branch 'suffix-rules-work' into micro * suffix-rules-work: NEWS: document fix for bug#14441 Automake::Rule: consistently prepend underscore to private variables Automake::Rule: rename: suffix_rule() -> next_in_suffix_chain() Automake::Rule: adjust comments and POD according to previous changes Automake::Rule: make private variables lexically scoped suffix rules: better distinction between builtin and user-derived Automake::Rule: expose suffix rules as a function, not a scalar tests: expose automake bug#14441
b1b1b299 2013-05-28 21:26:28 NEWS: fix typo Reported-by: Peter Rosin <peda@lysator.liu.se> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
7c53e4c3 2013-05-28 21:04:39 Merge branch 'micro' into maint * micro: NEWS: report recent documentation fix about AM_PROG_MKDIR_P NEWS: Automake 2.0 will assume "rm -f" without args work NEWS: fix a couple of typos in older entries
87e49f4f 2013-05-28 20:51:42 NEWS: report recent documentation fix about AM_PROG_MKDIR_P Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
15f610e7 2013-05-28 20:48:11 NEWS: Automake 2.0 will assume "rm -f" without args work Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
d987aa36 2013-05-28 20:09:54 NEWS: on assuming "rm -f" without arguments work Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
e6df383b 2013-05-28 19:29:11 NEWS: fix a couple of typos in older entries Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
a4c5b27b 2013-05-28 10:54:25 NEWS: document fix for bug#14441 Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
d6efe326 2013-05-26 13:54:29 NEWS: document deprecation of 'shar' and 'compress' dist formats Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
e5b40a3e 2013-05-26 13:30:52 Merge branch 'prog-cc-c-o-work' into maint * prog-cc-c-o-work: tests: some tests make no sense if "$CC -c -o" doesn't work AM_PROG_CC_C_O: don't rely on AC_PROG_CC_C_O, re-implement similar logic compile: rewrite AC_PROG_CC with AM_PROG_CC_C_O contents
d81424aa 2013-05-26 12:04:48 Merge branch 'micro' into maint * micro: tests: avoid a couple of extra sleep with GNU make NEWS: document testsuite work for 1.13.3 lint: remove a couple of obsolete syntax checks lint: cosmetics: use #-comments, not ##-comments lint: cosmetics: some reordering lint: recipes of syntax check require GNU grep; ensure it is used lint: better name for a syntax check tests: rename $am_make_rc_got -> $am_make_rc tests: ensure $required is not set too late Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
bf81b6d1 2013-05-26 11:23:29 NEWS: document testsuite work for 1.13.3 Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
e90126cf 2013-05-15 10:14:46 AM_PROG_CC_C_O: don't rely on AC_PROG_CC_C_O, re-implement similar logic ** Theoretical problems of AC_PROG_CC_C_O: Both cc and $CC are checked to see if they support the '-c' and '-o' options together. This behaviour is highly inconsistent with that of the other macros related to C compiler checks -- which test only $CC. It can also cause unwarranted uses of the 'compile' script on systems where the default 'cc' is inferior, but the user is compiling with a proper, different compiler (e.g., gcc). ** Practical problems with our previous implementation of C support m4 macros in Automake: - AM_PROG_AR must now be called *before* AC_PROG_CC; this wasn't the case before, and it turns out there are packages in the wild that relied on the old behaviour. - The cross-referenced requirements and macro rewrites juggled among AC_PROG_CC, AC_PROG_CC_C_O and AM_PROG_CC_C_O caused warnings in autoconf; for example, in our test 't/libobj3.sh', we could see warnings like these (here slightly tweaked for legibility): configure.ac:5: AC_REQUIRE: `AC_PROG_CC' expanded before required autoconf/c.m4:567: AC_PROG_CC_C_O is expanded from... autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from... autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from... autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from... m4sugar/m4sh.m4:639: AS_IF is expanded from... autoconf/general.m4:2031: AC_CACHE_VAL is expanded from... autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from... aclocal.m4:70: AM_PROG_AR is expanded from... configure.ac:5: the top level ** Fix all of that: We fix all of the described issues with a new internal m4 macro _AM_PROG_CC_C_O (inspired to, but not based on, AC_PROG_CC_C_O) that gets tacked on to AC_PROG_CC automatically (this is done in the Automake-generated aclocal.m4) and that takes care of checking and adjusting '$CC' for "-c -o" support. The macro AM_PROG_CC_C_O is still present, but is now just a thin wrapper around such Automake-enhanced AC_PROG_CC. It is worth noting that the present patch causes three slight *backward-incompatibilities*: 1. The name cache variable used by AM_PROG_CC_C_O is no longer computed (at configure runtime!) from the content of '$CC', but is statically defined as 'am_cv_prog_cc_c_o'. 2. 'cc' is no longer checked by AM_PROG_CC_C_O, only '$CC' is. 3. AM_PROG_CC_C_O no longer AC_DEFINE the C preprocessor symbol 'NO_MINUS_C_MINUS_O'. Given however that the third change can easily be worked around, that the first two changes can be legitimately seen as bug fixes, and that the new semantics introduced by such changes will simplify the transition to Automake 2.0 (when the 'subdir-objects' will always be enabled unconditionally), we believe they are acceptable to be shipped with Automake 1.14. With this patch, we also revert some of the testsuite adjustments done in previous commit v1.13.2-178-g9877109 of 2013-05-24 (compile: rewrite AC_PROG_CC with AM_PROG_CC_C_O contents). Such adjustments are no longer needed. * m4/minuso.m4 (_AM_PROG_CC_C_O): New internal macro, basically and adjusted version of a merge between Autoconf-provided AC_PROG_CC_C_O and our old implementation of AM_PROG_CC_C_O. (AM_PROG_CC_C_O): Redefine as a simple wrapper around AC_PROG_CC. * m4/init.m4 (AC_PROG_CC): Append _AM_PROG_CC_C_O, not AM_PROG_CC_C_O, to the pre-existing expansion of this macro. * m4/ar-lib.m4 (AM_PROG_AR): No longer require it to be expanded after AC_PROG_CC. * t/aclocal-deps.sh: Move AC_PROG_CC invocation after AC_PROG_RANLIB and AM_PROG_AR invocations. Things should work this way too (as they used to). * t/subobj-clean-lt-pr10697.sh: Likewise. * t/alloca.sh: Move AC_PROG_CC invocation after AM_PROG_AR invocation. * t/condlib.sh: Likewise. * t/aclocal-deps.sh: Move AC_PROG_CC invocation after LT_INIT and AM_PROG_AR invocations. Make autoconf and autoheader warnings fatal. * t/am-prog-cc-c-o.sh: Adjust to the new semantics, enhance a little, and reduce code duplication. * t/ccnoco.sh: Make autoconf warnings fatal. * t/subpkg.sh: Likewise. * t/ccnoco-lib.sh: Likewise, and fix a comment. * t/link_cond.sh: Enhance a couple of error messages. * configure.ac: Drop "nullification" of AM_PROG_CC_C_O. * NEWS: Adjust. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
0cca184f 2013-05-18 15:23:20 Merge branch 'micro' into maint * micro: lisp: fix a failure with Solaris /usr/xpg4/bin/sh tests: sanitize 'unset' usages tests: fix some botched/outdated comments tests: use perl, not find+rm, to remove temporary directories Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
0256f1d6 2013-05-18 13:35:16 lisp: fix a failure with Solaris /usr/xpg4/bin/sh * lib/am/lisp.am (.el.elc): By initializing the 'am__dir' properly here. For most shells, the lacking initialization, while technically incorrect, didn't cause any issue in practice, because in those shells "test -d" returns an exit status of 0. But with /usr/xpg4/bin/sh, the shell complains like this: "test: argument expected", and returns a non-zero exit status. This caused testsuite failures in several lisp tests. Also, while we are at it, use more proper quoting in the recipe, to ensure a missing initialization to now be caught by more forgiving shells as well. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
52a76013 2013-05-15 22:54:15 Merge branch 'micro' into maint * micro: post-release: micro version bump (1.13.2a) release: stable micro release 1.13.2 vala tests: skip in a cross compiler setup HACKING: miscellaneous fixes, updates and enhancements NEWS: minor improvements to wording (about new versioning scheme) Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
1a05e925 2013-05-15 19:13:13 NEWS: minor improvements to wording (about new versioning scheme) Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
b602d99c 2013-05-10 22:17:43 NEWS: typofix Reported-by: Eric Blake <eblake@redhat.com> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
7a2ff99d 2013-05-10 21:17:30 news: document new 'subdir-objects' warning * NEWS: Automake 1.14 will warn if a subdir source file is specified but the 'subdir-objects' option is not given. This is done to smooth the transition to Automake 2.0, which will unconditionally assume the behaviour now given only with the 'subdir-objects' option. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
0709f52f 2013-05-10 20:35:21 NEWS: fix a reference to Automake 1.14 where Automake 2.0 was intended Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
57cb996d 2013-05-05 00:52:01 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: maint: version bump after beta release 1.13.1d release: beta release 1.13.1d (will become 1.13.2) NEWS: document more robust handling/recognition of make options Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
8a11e2fd 2013-05-04 22:58:25 NEWS: document more robust handling/recognition of make options Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
e5e3a629 2013-04-30 23:03:50 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: cosmetics: remove few trailing whitespace occurrences typofix: in NEWS (extra whitespace)
8430d412 2013-04-30 22:59:30 typofix: in NEWS (extra whitespace) Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
96b1303d 2013-04-30 15:35:46 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: sync: update files from upstream with "make fetch" maintcheck: remove outdated whitelisting tar: format 'ustar' cannot support UID/GID longer than 21 bits Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
2a40fa71 2013-04-30 14:48:45 Merge branch 'fix-pr13588-pax-hangs' into branch-1.13.2 * fix-pr13588-pax-hangs: tar: format 'ustar' cannot support UID/GID longer than 21 bits
edfd3bc4 2013-02-17 16:42:46 tar: format 'ustar' cannot support UID/GID longer than 21 bits See automake bug#8343 and bug#13588. POSIX 1988 'ustar' format is defined with *fixed-size* fields. There is notably a 21 bits limit (2097151) for the UID and the GID. Tom Rini tom_rini@mentor.com says (in bug#8343): When the user has a UID or GID that is larger than the ustar format supports, pax does not error out gracefully in some cases (FC13). Marc Herbert <marc.herbert@intel.com> adds (in bug#8343): When "configure" is run by a user with an UID bigger than 21 bits, BSD pax 3.4 aborts when trying to create the 'conftest.tar' test archive and leaves an empty or corrupted conftest.tar file behind. In the next step, pax tries to extract this incomplete or corrupted archive and this *** hangs the whole ./configure script ***. Note: GNU cpio 2.9 pretends to pass the test but it is a LIE: it silently truncates any big UID to its lower 21 bits. I don't know what can be the consequences of this lie. I think there is currently a design issue in automake/m4/tar.m4 considering that a ustar archive should should *never* succeed when ./configure is run from a big user ID. Months later, Petr Hracek <phracek@redhat.com> reports a similar issue (in bug#13588) for Fedora 17: I am trying to solve problem in case a user is created with big UID and during configuration pax hangs with message ATTENTION! pax archive volume change required. Ready for archive volume: 1 Input archive name or "." to quit pax. Archive name > and needs user interaction. Reference: <https://bugzilla.redhat.com/show_bug.cgi?id=843376> Time to fix this issue, on the line of a preliminary patch provided by Petr Hracek in bug#13588. The final patch ended up being remarkably different from that original proposition, though. * m4/tar.m4 (_AM_PROG_TAR): If the UID or GID of the current user is too high (> 2097151), the 'ustar' format cannot work. Adjust checks accordingly. Some related code reordering and clean-up. * t/tar-ustar-id-too-high.sh: New test. * t/list-of-tests.mk: Add it. * t/tar.sh: While at it, tweak and enhance a little. * t/tar2.sh: Likewise. * t/tar3.sh: Likewise. * t/tar-override.sh: Likewise. * NEWS: Update. * THANKS: Likewise. Helped-by: Pavel Raiskup <praiskup@redhat.com> Helped-by: Petr Hracek <phracek@redhat.com> Helped-by: Marc Herbert <marc.herbert@intel.com> Helped-by: Tom Rini <tom_rini@mentor.com> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
f0d1288f 2013-04-26 20:39:40 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: docs: issues with configure substitutions in TESTS tests: avoid possible autotools caching issues (automake bug#13832) docs: add myself and Ralf Wildenhues as authors authors: add myself dry-run: don't get confused by '-I' option tests: avoid a spurious failure with the Korn Shell dry-run: with GNU make, prefer $(MFLAGS) over $(MAKEFLAGS) header vars: can determine whether we are running under GNU make NEWS: improve wording for automake bug#13514 fix NEWS: document fix for automake bug#13514
2d47361d 2013-04-21 16:59:05 NEWS: improve wording for automake bug#13514 fix Helped-by: Jack Kelly <jack@jackkelly.name> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
40f949c7 2013-04-21 10:38:29 NEWS: document fix for automake bug#13514 It was fixed by commit v1.13.1b-5-g7a3d7ce. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
00f911e7 2013-04-19 16:12:48 NEWS (mint): reflect new Automake versioning scheme The next minor Automake version will be 1.14, and *not* 1.13.2 -- that will be the next bug-fixing version. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
9cbd5436 2013-03-05 15:58:49 Merge branch 'preproc' into maint * preproc: preproc: enhance and extend tests preproc: add support for relative names in included fragments Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
b4dbcb75 2013-02-21 16:10:16 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: aclocal: fix for more-than-once specified directories aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
a8933e87 2013-02-21 15:35:04 Merge branch 'fix-pr13514' into branch-1.13.2 * fix-pr13514: aclocal: fix for more-than-once specified directories aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
5daad702 2013-02-20 22:14:55 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: coverage: expose automake bug#13760 tests: refactor/enhance tests about make dry-run mode maint: describe new versioning and branching scheme, and adjust to it Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
c83c1335 2013-02-11 13:11:51 aclocal: just warn if the primary local m4 dir doesn't exist (don't error) Related to automake bug#13514. Every package which does not need to have the local m4 macro directory pre-existing in the version control system (because e.g., it does not have nor need any private m4 macros) would fail during the "autoreconf -vfi" phase if AC_CONFIG_MACRO_DIRS([m4]) is specified in configure.ac (it could be to instruct tools like 'autopoint' and 'libtoolize' to use 'm4' as the local directory where to install definitions of their m4 macros, and to instruct aclocal to look into it). The failure would go like this: autoreconf: Entering directory `.' autoreconf: running: aclocal --force aclocal: error: couldn't open directory 'm4': No such file or directory autoreconf: aclocal failed with exit status: 1 The problem is that when 'aclocal' is run for the first time during 'autoreconf', the directory 'm4' does not exist yet. It will be created by e.g., 'libtoolize' or 'autopoint' later on. During the second 'aclocal' run, the 'm4' directory exists and aclocal does not complain. To work around this issue, we degrade the error to a simple warning. The warning is still quite useful when aclocal is run by hand - so we are not removing completely. See also: <http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html> <http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663> <https://bugzilla.redhat.com/show_bug.cgi?id=901333> * aclocal.in (SCAN_M4_DIRS_SILENT, SCAN_M4_DIRS_WARN) (SCAN_M4_DIRS_ERROR): New constants. (scan_m4_dirs): Change the second parameter name to $ERR_LEVEL to better reflect new semantic. Use new constants. (scan_m4_files): Adjust to reflect the new 'scan_m4_dirs' semantics. * t/aclocal-macrodir.tap: Adjust. * t/aclocal-macrodirs.tap: Likewise. * THANKS: Update. * NEWS: Likewise. Suggested-by: Ben Pfaff <blp@cs.stanford.edu> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
97aaf121 2013-02-17 10:25:29 maint: describe new versioning and branching scheme, and adjust to it See discussion about automake bug#13578 for more details and background. Basically, for the versioning scheme: - micro versions only for bug and regression fixing; - minor versions for new backward-compatible features, and new non-fatal deprecations; - major versions for backward-incompatibilities, complex new features, and major refactoring. And for the git branching scheme: + branch 'next' is for the upcoming major version; + branch 'master' is now for the upcoming minor version; + branch 'maint' is for the upcoming micro (bug-fixing) version; + the merging hierarchy is: 'maint' -> 'master' -> 'next'. * HACKING (Automake versioning and compatibility scheme): New. (Working with git): Adjust. * NEWS: Update and fix. * aclocal.in: Adjust some "FIXME" messages. * automake.in: Likewise. * m4/mkdirp.m4: Likewise. * t/aclocal-acdir.sh: Likewise. * t/aclocal-macrodir.tap: Likewise. * t/aclocal-macrodirs.tap: Likewise. * lib/Automake/Options.pm: Likewise. * m4/internal/ac-config-macro-dirs.m4: Likewise. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
f637fc39 2013-02-15 15:06:19 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: typofix: in comments in 't/ax/test-lib.sh' tests on TAP: don't run the driver with perl unconditionally typofix: in comments in 'automake.in' tests: remove obsolete (and now wrong) comment typofix: in diagnostic in test 't/tap-realtime.sh' automake: fix reference to relevant tests in comments NEWS: we no longer plan to drop $(INCLUDES) support in next major version
ba25a9f1 2013-02-08 09:11:45 preproc: add support for relative names in included fragments The rationale for this change is that it is annoying to have to repeat the directory name when including a Makefile fragment. For deep directory structures these repeats can generate a lot of bloat. It also hinders reuse and easy directory restructuring if all Makefile fragments have to know exactly where they live. Suggested by Bob Friesenhahn, and later discussed in bug#13524. In the course of discussion, the following notations were rejected: &{reldir}& - to hard to type, {reldir} - interferes with ${reldir}, {am_reldir} - short form {D} interferes with ${D}, @am_reldir@ - short form @D@ interferes with AC_SUBST([D]) as well as invading the config.status turf. Other notations were also suggested... * automake.in (read_am_file): Add third argument specifying the relative directory of this Makefile fragment compared to the main Makefile. Replace %reldir% and %canon_reldir% in the fragment with this relative directory (with slashes etc, or canonicalized). (read_main_am_file): Adjust. * t/preproc-reldir.sh: New test. * t/list-of-tests.mk: Augment. * doc/automake.texi (Include): Document the new feature. NEWS: Add new feature. Co-authored-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Peter Rosin <peda@lysator.liu.se> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
711fb0c7 2013-02-03 20:16:01 NEWS: we no longer plan to drop $(INCLUDES) support in next major version For a rationale and related discussion, see: <http://lists.gnu.org/archive/html/automake/2013-02/msg00001.html> And note that support for INCLUDES has not been re-introduced in the master branch yet, at the moment of writing; but we plan to definitely do so before the next major release. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
0756a43c 2013-01-28 13:33:00 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: NEWS: IRIX is still supported; only SGI C compiler depcomp no longer is maint: version bump after beta release 1.13.1b NEWS: typofix release: beta release 1.13.1b (will become 1.13.2) Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
97f04a5d 2013-01-28 13:22:12 NEWS: IRIX is still supported; only SGI C compiler depcomp no longer is This change is for the maint branch. The only IRIX-specific support that is going to actually be removed in the next major Automake versions is the depcomp support for the SGI compiler. That means that automatic dependency tracking will no longer work with that compiler, but "normal" compilation should still work, at least until the compiler is supported by Autoconf. So there is no point in alarming our users by stating in the NEWS file that "support for IRIX and the SGI compilers is going to be removed"; after all, while we don't test on nor particularly care about IRIX anymore, that doesn't mean we are deliberately breaking it, and the likelihood of an intended breakage there is very low. See: <http://lists.gnu.org/archive/html/automake-patches/2013-01/msg00164.html> <http://lists.gnu.org/archive/html/automake-patches/2013-01/msg00165.html> * NEWS (Future backward-incompatibilities: Adjust. Improve explanation of our rationale for dropping SGI support. Fix an unrelated typo while at it. Suggested-by: Peter Rosin <peda@lysator.liu.se> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
0a0f3ba6 2013-01-23 11:33:09 NEWS: typofix Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
c3db2386 2013-01-22 13:37:41 Merge branch 'branch-1.13.2' into maint * branch-1.13.2: docs: '.txi' and '.texinfo' extensions are deprecated NEWS: document recent documentation improvements docs: more precise cross reference docs: 'dist-shar' and 'dist-tarZ' are obsolescent today docs: improve documentation of 'dist-*' targets slightly docs: make even clearer 'dist-gzip' is the default. docs: document 'dist-xz' together with the other 'dist-*' options docs: 'no-define' option and AM_INIT_AUTOMAKE three-args usage: fixlets warn: correct broken hyperlink in warning message Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
b6197589 2013-01-22 13:14:41 NEWS: document recent documentation improvements Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
63fe125a 2013-01-21 14:52:37 Merge branch 'branch-1.13.2' into maint That branch is for the "emergency" bug-fixing release 1.13.2. * branch-1.13.2: maint: update copyright in files generated by automake and aclocal tests: avoid a spurious failure when running inside Emacs tests: make two new test executable m4: rename an m4 file to a more appropriate name NEWS: update w.r.t. recent documentation fixes compat: reinstate AM_CONFIG_HEADER and AM_PROG_CC_STDC docs: parallel-tests is no longer experimental docs: serial-tests are not deprecated, just discouraged NEWS: we are not going to remove AM_PROG_MKDIR_P in Automake 1.14 Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
4d32ebdd 2013-01-18 13:32:12 NEWS: update w.r.t. recent documentation fixes Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
eada7ef7 2013-01-18 13:13:30 compat: reinstate AM_CONFIG_HEADER and AM_PROG_CC_STDC Make them give runtime warnings in the obsolete category, but apart from that, make them behave as they did in Automake 1.12.x and earlier. While removing those macros seemed quite harmless, because it didn't put a real burden on the developers (requiring them just to do a quick edit to configure.ac), it turned out to place an unsustainable burden (or at least, a burden perceived as such) on distro packagers who use the latest Automake to bootstrap existing packages. Many of those packages, while having likely updated to AC_CONFIG_HEADERS in their development version, still used AM_CONFIG_HEADER in their existing released versions, and the removal of this macro would have thus forced the Fedora packagers to patch all of them. References: <http://www.mail-archive.com/devel@lists.fedoraproject.org/msg52840.html> <http://www.spinics.net/lists/fedora-devel/msg175922.html> <http://blog.flameeyes.eu/2013/01/autotools-mythbuster-automake-pains> In addition, the Fedora packagers have already decided to patch their Automake 1.13.1 to reinstate the AM_CONFIG_HEADER and AM_PROG_CC_STDC macros (plus other macros that I don't believe it's worth worrying about): <http://www.spinics.net/lists/fedora-devel/msg176098.html> <http://www.mail-archive.com/devel@lists.fedoraproject.org/msg53030.html> <http://pkgs.fedoraproject.org/cgit/automake.git/commit/?id=ffe6bc39> So, rather than having one more incompatibility floating around, we better mirror that change (or, actually, its relevant parts) in the upstream. * m4/obsolete-err.m4 (AM_CONFIG_HEADER, AM_PROG_CC_STDC): Revert to the older semantics, plus a runtime warning in the 'obsolete' category. * t/backcompat6.sh: Use AM_CONFIG_HEADER once again. * t/am-config-header-no-more.sh: Rename ... * t/am-config-header.sh: ... like this, and adjust. * t/am-prog-cc-stdc-no-more.sh: Rename ... * t/am-prog-cc-stdc.sh: ... like this, and adjust. * t/list-of-tests.mk: Adjust. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
ae4d4fcf 2013-01-18 11:04:25 NEWS: we are not going to remove AM_PROG_MKDIR_P in Automake 1.14 See commit v1.13.1-109-g030ecb4 of 2013-01-16, "compat: restore AM_PROG_MKDIR, again", for the rationale. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
34001a98 2013-01-09 23:16:53 compile: use 'compile' script when "-c -o" is used with losing compilers Do so seen when only source files in the "current" directory are present. This commit is part of a series of related changes addressing automake bug#13378 (see also the plan 'PLANS/subdir-objects.txt'). Before this change, Automake-generated C compilation rules mistakenly passed the "-c -o" options combination unconditionally (even to losing compiler) when the 'subdir-objects' was used but sources were only present in the top-level directory. Issue spotted by Nick Bowler: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44> We fix this by having Automake redefine AC_PROG_CC to take over the role of AM_PROG_CC_C_O and to require the 'compile' script unconditionally (albeit that will continue to be invoked only when inferior compilers are detected). Among other things, this means AM_PROG_CC_C_O explicitly is no longer required; that macro is still supported for backward-compatibility, but calling it is basically a no-op now. This change has some pros and some cons (obviously, we believe the former outweighs the latter). Here are the most relevant ones: + Pros 1: Some logic in the Automake script has been simplified. + Pros 2: That simplification has automatically fixed an actual bug (see Nick's mails referenced above; admittedly, that was present only in corner-case situations, but still); the test 't/ccnoco4.sh', which demonstrated the bug and has been failing so far, now passes. + Pros 3: Things works more "automagically" now (no need to manually add the AM_PROG_CC_C_O macro to configure.ac anymore). * Cons 1: The 'compile' script will be required in all projects using C compilation; this will only be a problem for packages not using '--add-missing'. However, such packages are definitely more rare than the ones using '--add-missing', and adjusting them will be trivial -- just copy the compile script over from the new Automake installation. * Cons 2: The copy & paste of autoconf internals hack this change has introduced in our "rewrite" of AC_PROG_CC is really an egregious abomination. It can only be justified with the fact that we expect future versions of autoconf to implement the semantics we need directly in AC_PROG_CC, so that we'll be able to leverage that (since Automake 1.14 will require the latest Autoconf version released). Now, the detailed list of file-by-file changes ... * automake.in ($seen_cc_c_o): Remove this global variable. (scan_autoconf_traces): Don't set it, and do not trace the 'AM_PROG_CC_C_O' m4 macro. (lang_c_rewrite): Remove, no longer needed. * doc/automake.texi: Adjust expected "autoreconf --install" output in the amhello example. Remove statements about the need for the AM_PROG_CC_C_O macro. Report it is obsolete now. * m4/init.m4: Re-write AC_PROG_CC to append checks about whether the C compiler supports "-c -o" together. These checks have basically been ripped out (with adaptations) from the 'AC_PROG_CC_C_O' macro of Autoconf and ... * m4/minuso.m4 (AM_PROG_CC_C_O): ... this macro of ours, which has thus basically become a no-op. * t/ax/am-test-lib.sh (am_setup_testdir): Also copy the 'compile' script in the test directory; if we don't do so, every test using AC_PROG_CC should call automake with the "--add-missing" option, or copy the 'compile' script itself. * t/cond11.sh: No need to create a dummy 'compile' script: that is already brought in by 'am_setup_testdir()', that is automatically invoked when 'test-lib.sh' is sourced. * t/add-missing.tap: Adjust: we expect the 'compile' script to be required by a mere AC_PROG_CC call now. * t/dist-auxdir-many-subdirs.sh: Likewise. * t/specflg6.sh: Likewise. * t/subobj4.sh: Likewise. * t/cxx-lt-demo.sh: Likewise, and update comments to match. * t/distcom2.sh: Enhance a little. * t/dollarvar2.sh: Adjust. * t/extra-portability.sh: Likewise. * t/libobj19.sh: Likewise. * t/per-target-flags.sh: Likewise. * t/repeated-options.sh: Likewise. * t/subobj.sh: Likewise, and enhance a little. * t/ccnoco2.sh: Remove as obsolete. * t/list-of-tests.mk (handwritten_TESTS): Adjust. (XFAIL_TESTS): Remove 't/ccnoco4.sh'. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
a5ebf351 2013-01-03 19:02:52 NEWS: improve wordings in entry deprecating suffix-less info files Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
0b1576ae 2013-01-03 13:27:26 Merge branch 'info-in-builddir' into maint * info-in-builddir: texi: deprecate hack about info files in CLEANFILES variables texi: info files can be generated in the builddir Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
1c48cbe0 2013-01-01 23:06:36 docs: re-introduce mention of two-args AM_INIT_AUTOMAKE invocation Albeit obsolescent and raising warnings in the 'obsolete' category, that usage is still supported, and will need to be until Autoconf improves its handling of configure-time-generated package version numbers. So it's better to explicitly document it again, stating that it is obsoleted but still working (and why), rather then leaving it as Yet Another Undocumented Feature (that will mysteriously and suddenly break some random day in the future). It's worth giving some background about how we ended up in the situation that this patch fixes. We had originally removed support for the long-deprecated two-args AM_INIT_AUTOMAKE invocation (see commit v1.12-67-ge186355). Before that removal could land in a released Automake version, Bob Friesenhahn made a quite compelling point that the two-args AM_INIT_AUTOMAKE invocation could still be useful for modern, maintained packages like GraphicsMagick, at least until Autoconf is fixed to offer better support for "dynamic" package versions (see commit v1.12.2-245-g2abe183 for more in-depth rationales and references). However, in that commit we didn't revert the removal of the *documentation* for this two-arguments AM_INIT_AUTOMAKE invocation (and no rationale for not doing so was given in the commit message). Time to remedy that. Indirectly suggested by Diego Elio Pattenò: <http://blog.flameeyes.eu/2013/01/autotools-mythbuster-automake-pains> * doc/automake.texi: Adjust. * NEWS: Update. * THANKS: Likewise. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
e1ed3145 2013-01-01 22:34:15 texi: warn against '.txi' and '.texinfo' input suffixes The warning being in the 'obsolete' category. This is mostly to ease transition to Automake-NG (see commit v1.12.1-416-gd5459b9), and to discourage use of seldom-tested setups. * automake.in (handle_texinfo_helper): Warn against Texinfo input files with '.txi' or '.texinfo' suffixes. * NEWS: Update. * t/txinfo-other-suffixes.sh: Adjust and enhance. * t/txinfo-no-repeated-targets.sh: No longer use '.txi' and '.texinfo' extensions. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
2af418d1 2013-01-01 20:59:53 texi: warn against suffix-less info files The warning being in the 'obsolete' category. This is mostly to ease transition to Automake-NG (see commit v1.12.1-392-ga0c7b6a), and to discourage use of seldom-tested setups. * automake.in (scan_texinfo_file): Warn against '@setfilename' directives that specify suffix-less output info files. * t/txinfo-without-info-suffix.sh: Adjust and enhance. * t/txinfo-makeinfo-error-no-clobber.sh: No longer use suffix-less info files in '@setfilename' directives. * t/primary-prefix-valid-couples.sh: Likewise. * t/txinfo-setfilename-repeated.sh: Likewise. * t/txinfo-vtexi2.sh : Likewise. * t/mdate2.sh: Likewise. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
c1a8f562 2013-01-02 00:33:42 texi: deprecate hack about info files in CLEANFILES variables For quite a long time, Automake has been implementing an undocumented hack which ensured that '.info' files which appeared to be cleaned (by e.g. being listed in the CLEANFILES or DISTCLEANFILES variables) were built in the builddir rather than in the srcdir; this hack was introduced to ensure better backward-compatibility with packages such as Texinfo, which did things like: info_TEXINFOS = texinfo.txi info-stnd.texi info.texi DISTCLEANFILES = texinfo texinfo-* info*.info* # Do not create info files for distribution. dist-info: @: in order not to distribute .info files. Now that we have the 'info-in-builddir' option that explicitly causes generated '.info' files to be placed in the builddir, this hack should be longer necessary, so we deprecate it with runtime warnings. It is scheduled to be removed altogether in Automake 1.14. * automake.in (handle_texinfo_helper): Raise proper runtime warnings if the hack is triggered. * NEWS: Update. * t/txinfo28.sh: Adjust. * t/txinfo23.sh: Likewise. * t/txinfo25.sh: Adjust and extend. * t/txinfo24.sh: Likewise. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
36ee783a 2012-04-03 22:02:55 texi: info files can be generated in the builddir User can now ask info files to be built in the $(builddir), rather than the $(srcdir), by specifying the Automake option 'info-in-builddir'. This feature was requested by the developers of GCC, GDB, GNU binutils and the GNU bfd library. See the extensive discussion about automake bug#11034 for more details. OK, to be honest, having '.info' files built in the builddir was *already* possible, but only using ugly and undocumented hacks involving definition of the CLEANFILES and/or DISTCLEANFILES. For example, the binutils project did something like this in the relevant 'Makefile.am': # Automake 1.9 will only build info files in the objdir if they are # mentioned in DISTCLEANFILES. It doesn't have to be unconditional, # though, so we use a bogus condition. if GENINSRC_NEVER DISTCLEANFILES = binutils.info endif See also the extensive discussion about automake bug#11034; in particular, the following messages: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#65> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#80> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#86> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#101> * lib/Automake/Options.pm (_is_valid_easy_option): Recognize the new 'info-in-builddir' option. * automake.in (handle_texinfo_helper): If that option is set, initialize '$insrc' to '0', so that info files will be generated in the builddir. Adjust comments to match. * t/txinfo-builddir.sh: New test. * t/list-of-tests.mk: Add it. * NEWS: Update. * doc/automake.texi: Document the new options. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
2af1069b 2013-01-01 13:56:32 NEWS: fixlets and updates Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
7df8b28c 2012-12-31 18:18:37 maint: update copyright year for 2013 (in branch maint) Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
68990859 2012-12-30 11:24:44 NEWS: minor fixup Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
9c07d892 2012-12-30 11:04:39 obsolete: better error message if AM_PROG_CC_STDC is used In Automake 1.13, the long-deprecated (since 2002) macro AM_PROG_CC_STDC has been removed. Such a removal, albeit sensible and justified, was probably done in a too-abrupt way, since it didn't turn the pre-existing warning messages into fatal error messages, but simply dropped the macro definition, so that remaining usages of it would cause unclear error messages, e.g.: configure.ac:4: warning: macro 'AM_PROG_CC_STDC' not found in library from aclocal, and: configure.ac:4: error: possibly undefined macro: AM_PROG_CC_STDC If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. from autoconf. In an attempt to mitigate this issue, we re-add an AM_PROG_CC_STDC definition that simply raises a *clear* error message when the macro is used. * t/am-prog-cc-stdc-no-more.sh: New test. * t/list-of-tests.mk: Add it. * m4/obsolete-err.m4: Add the new "error-raising" definition for AM_PROG_CC_STDC; the error message is a variation of the one already present in the older version of this macro, before it got removed in commit 'v1.12-15-gd2ca168'. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
8e921bf8 2012-12-30 10:33:23 obsolete: better error message if AM_CONFIG_HEADER is used In Automake 1.13, the long-deprecated macro AM_CONFIG_HEADER (deprecated since 2002) has been removed in favour of AC_CONFIG_HEADERS. However, the removal was done without a proper deprecation period, and that caused packages upgrading to Automake 1.13 to fail with very unclear error messages, e.g.: configure.ac:4: warning: macro 'AM_CONFIG_HEADER' not found in library from aclocal, and: configure.ac:4: error: possibly undefined macro: AM_CONFIG_HEADER If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. from autoconf. In an attempt to mitigate this issue, we re-add an AM_CONFIG_HEADER definition that simply raises a *clear* error message when the macro is used. Report by Paolo Bonzini: <http://lists.gnu.org/archive/html/automake/2012-12/msg00039.html> * t/am-config-header-no-more.sh: New test. * t/list-of-tests.mk: Add it. * m4/obsolete-err.m4: New file, contain the new AM_CONFIG_HEADER "error-raising" definition, as well as the definition of the similarly obsolete macros 'AM_C_PROTOTYPES' and 'fp_C_PROTOTYPES', moved in from ... * m4/protos.m4: ... this file, which has thus been removed. * Makefile.am (dist_automake_ac_DATA): Adjust. * t/ansi2knr-no-more.sh: Likewise. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
c010d62f 2012-12-24 10:44:10 news: fix botched URL Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
27eb4254 2012-12-19 14:51:58 ylwrap: various fixes Rename properly header guards in generated header files, instead of leaving Y_TAB_H. Convert header guards in implementation files. Because ylwrap failed to rename properly #include in the implementation files, current versions of Bison (e.g., 2.7) duplicate the generated header file in the implementation file. The header guard then protects the implementation file from duplicate definitions from the header file. Generate header guards with a single '_' for series of non alphabetic characters, instead of several. This is what Bison does. Makes the test t/yacc-d-basic.sh pass again. * lib/ylwrap (guard): Properly honor $1 to rename properly the header guards. Keep a single _ instead of several. (rename_sed): Rename as... (sed_fix_filenames): this. Suggested by Stefano Lattarini. (sed_fix_header_guards): New. Use it.
31a07e69 2012-12-19 18:19:42 NEWS: we plan to ditch MS-DOS/DJGPP support in future Automake versions Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
4fd9dcd6 2012-12-19 12:05:08 NEWS: fix grammaro Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
fba280d0 2012-12-16 13:36:14 NEWS: start preparing for the 1.13 release * NEWS: Here. In particular, list (some of) the planned future backward-incompatibilities that will take place in Automake 1.14. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
6a38d740 2012-11-27 21:05:25 Merge branch 'depcomp-work' * depcomp-work: depcomp: remove 'icc' depmode, add 'tcc' one news: update w.r.t. recent depcomp changes tests: fix spurious failures with tcc depcomp: improve comments about tcc support depcomp: remove last relics of libtool 1.4 support depcomp: remove an unused variable depcomp: rewrite a sed invocation for less quoting depcomp: whitespace fixes depcomp: shell code style changes depcomp: make some code more self-documenting depcomp: less duplication between AIX and Tru64 modes depcomp: avoid an extra fork when possible depcomp: reduce code duplication depcomp: don't rely on character ranges working as in C locale depcomp: cosmetic fixlets to a comment depcomp: safer quoting in variable expansion depcomp: correctly propagate exit status in exit trap depcomp: use "rmdir", not "rm -rf", to remove the empty lock directory depcomp: remove useless quoting in variable definitions depcomp: be more idiomatic in checking for zero exit statuses
10ebd158 2012-11-27 20:46:32 Merge branch 'maint' * maint: news: we'll remove AM_PROG_MKDIR in 1.14, not 1.13 tests: give few vala tests more significant names vala tests: don't use the 'posix' profile, it's no longer supported news: fixup: bug#8847 is fixed in 1.12.6, not in 1.12.5 news: document the fix for automake bug#10227 tests: fix a spurious testsuite failure on Solaris python: make installed modules find by default on Debian and Ubuntu
54ec1e6b 2012-11-26 15:26:44 news: we'll remove AM_PROG_MKDIR in 1.14, not 1.13 See also commit v1.12.4-158-gdf23daf. * NEWS (Future backward-incompatibilities): Adjust accordingly. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
3e98c9d6 2012-11-26 14:48:29 vala tests: don't use the 'posix' profile, it's no longer supported Fixes automake bug#12934 a.k.a. bug#12522. Some of automake's Vala tests used to rely on "valac --profile posix" (which makes it not use glib). However, the posix profile was removed in August 2012, and is no longer present in the GNOME 3.6.2 version of valac (see commit ca020bf0 in the vala Git repository). Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> * t/vala-libs.sh: Adjust to avoid using the posix profile. * t/vala-mix.sh: Likewise. * t/vala-mix2.sh: Likewise. * t/vala-parallel.sh: Likewise. * t/vala-vapi.sh: Likewise. * t/vala-vpath.sh: Likewise. * NEWS: Update and adjust. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
1df23e4a 2012-11-26 13:33:45 news: fixup: bug#8847 is fixed in 1.12.6, not in 1.12.5 * NEWS (Bugs fixed in 1.12.5): So move it from here ... (Bugs fixed in 1.12.6): ... to here. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
691a1a82 2012-11-26 13:01:46 news: document the fix for automake bug#10227 This is a follow-up commit for v1.12.5-14-g1f113f6. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
0ff68f95 2012-10-18 21:07:56 depcomp: remove 'icc' depmode, add 'tcc' one According to the comments in the now-removed test 'depcomp5.test' (removed by commit 'v1.11-1829-g5066c1b' of 2012-02-08, "tests: improve and rework tests on dependency tracking") "icc 8.0 and greater understand gcc options, so depmode is set to gcc". According to Wikipedia, the 8.0 version of the Intel C compiler has been released in December 2003, that is, almost nine yeas ago. So we can remove explicit support for icc 7.x from the depcomp script. Since our support for tcc has so far been relied on the icc depmode, we must write a new explicit 'tcc' depmode. That is easy to do, since we can rely on the simpler and better-specified format of tcc-specified makefiles; for more info, see: <http://lists.gnu.org/archive/html/automake/2012-10/msg00043.html> * lib/depcomp (icc): Remove. (tcc): New. * NEWS: Update. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
487cf08d 2012-10-18 17:17:17 news: update w.r.t. recent depcomp changes * NEWS: Here. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>