configure: search a sturdy POSIX shell to be used in the testsuite
* configure.ac: Add code (partially inspired to checks in gnulib's
'tests/init.sh') to search for a good-enough, not-buggy POSIX/XSI
shell to be used in our testsuite. Accordingly AC_SUBSTitute the
variable 'AM_TEST_RUNNER_SHELL'.
* NEWS: Update.
bootstrap: consistently use correct copyright year
Suggested by Peter Johansson in the discussion about automake bug#11356:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11356#41>
* boostrap.sh (dosubst): Don't initialize the substituted value for the
release year from the current year (using `date +%Y`); instead, do it
through ...
($RELEASE_YEAR): ... this new statically-defined variable. To ensure it
won't get out-of-sync, it will be automatically updated ...
* Makefile.am (update-copyright): ... by this target's recipe.
Since are at it, fix a botched output redirection for an error message,
i.e., use ">&2" instead of ">&1".
Autoconf 2.65 is almost three years old now, so requiring it is
acceptable. Also, the soon-to-appear support for Objective C++
in Automake will be simplified if we can assume that Autoconf
version (which is the one that introduced support for Objective
C++).
* NEWS (Planned future backward-incompatibilities): Automake 1.13
will require Autoconf 2.65 or later.
readme: update INSTALL to latest version from Autoconf
* INSTALL: Updated to the version coming with Autoconf 2.69. This
is warranted now that we use and require that same Autoconf version
in our build system.
color-tests: coloring can be forced on non-ANSI terminals as well
Before this change, colorization of testsuite output was suppressed
whenever the terminal was recognized to be a "dumb" one, incapable
of handling ANSI coloring (i.e., when the environment variable TERM
had a value of "dumb"). This happened even when the AM_COLOR_TESTS
variable was set to a value of "always".
Such a behaviour was suboptimal and slightly confusing; in fact, if
a user wants to force coloring of testsuite output that is being
redirected to a regular file, he should be able to do so even if his
terminal is not capable of handling ANSI colors -- in fact, such
terminal wouldn't be involved with the testsuite output in any way,
so why should it be allowed to influence it?
Thus, we now enable coloring of test output whenever AM_COLOR_TESTS
is set to "always", irrespective of the value of the TERM environment
variable.
* NEWS: Update.
* lib/am/check.am [%?COLOR%] (am__tty_colors): Activate colorization
of testsuite output whenever AM_COLOR_TESTS has the value of "always".
* t/ax/tap-summary-aux.sh: Export the TERM environment variable to
"dumb" when forcing colorization of the testsuite output; this should
*not* prevent such colorization from taking place, and we want to
check that this expectation really holds.
* t/ax/testsuite-summary-checks.sh: Likewise.
* t/color.sh: Likewise, and adjust some grepping checks.
* t/tap-color.sh: Likewise. Also, remove redundant "make check"
invocation since we are at it.
* t/color2.sh: Likewise, and check that exporting TERM=dumb actually
prevents testsuite output colorization when AM_COLOR_TESTS is unset.
* t/parallel-tests-reset-term.sh: Relax, to prevent it from failing
spuriously due to the new semantic.
AM_PROG_MKDIR_P: deprecate, to be removed in Automake 1.13
Support for the obsolescent 'AM_PROG_MKDIR_P' macro (and its
output variable '$(mkdir_p)') has already been deprecated in
the documentation. It's now time to make its use actively
emit warnings in the 'obsolete' category as well.
* automake.in (scan_autoconf_traces): Warn about 'AM_PROG_MKDIR_P'
obsolescent if that macro is seen.
* m4/mkdirp.m4 (AM_PROG_MKDIR_P): Warn about its own obsolescence.
* m4/init.m4: Require 'AC_PROG_MKDIR_P', not 'AM_PROG_MKDIR_P'.
* t/mkdirp-deprecation.sh: New test.
* t/list-of-tests.mk: Add it.
* syntax-check.mk (sc_mkdir_p): Delete this check as obsolete.
(syntax_check_rules): Remove it.
* t/gettext-macros.sh: Ensure the gettext-requiring tests will
call aclocal and automake with the 'obsolete' warnings disabled,
since even recent versions of gettext used the now-deprecated
'AM_PROG_MKDIR_P' m4 macro.
* NEWS: Update.
fixup: avoid unconditional re-bootstrapping on "make dist"
Since our 'bootstrap' script is distributed, the 'distdir' target depends
on it. But in our GNUmakefile, we also have a 'bootstrap' target declared
.PHONY, which when called re-bootstrap the Automake distribution. Thus,
whenever we run "make dist", GNU make sees it must remake the 'bootstrap'
target (as it is a dependency of the 'distdir' target), and thus ends up
re-bootstrapping all the package (because of the .PHONY 'bootstrap' target
in GNUmakefile).
We fix this issue by renaming our bootstrap script to 'bootstrap.sh'.
build: ensure release year in copyright notice is up-to-date
From a suggestion by Eric Blake. See automake bug#11356.
This is a follow-up to previous patch 'v1.12-12-gb99b5be'.
* configure.ac (RELEASE_YEAR): New AC_SUBST'd variable, should hold
the value of the current year.
* Makefile.am (update-copyright): Be sure to also update the
definition of 'RELEASE_YEAR' in configure.ac.
* lib/Automake/Config.in ($RELEASE_YEAR): New exported variable,
initialized from the value substituted for '@RELEASE_YEAR@'.
(@EXPORT): Add it.
* automake.in, aclocal.in: Use '$RELEASE_YEAR' (which will be
substituted at make time) instead of hard-coding the release
year. This should ensure the copyright range in the version
message and in the generated files (Makefile.in and aclocal.m4)
are automatically kept up-to-date.
* bootstrap (dosubst): Update, also substitute '@RELEASE_YEAR@'.
* THANKS: Use spaces, not tabs, to separate a reporter's name from
his e-mail address. Also, increase such spacing, to allow a more
consistent formatting with longer names.
readme: explicitly state we use ranges in copyright years
Reported by Jack Kelly in automake bug#11356.
* README: Explicitly state we use ranges in copyright years; this is
mandated by the GNU Coding Standards for each package that wants to
actually use ranges in copyright years.
Dependencies in the Automake build system are not completely specified
(see for example the commit log of recent commit 'v1.12-10-gab14841',
"build: avoid too greedy rebuilds in the testsuite"). In fact, some of
them cannot even be; for example, Makefile is generated at configure
time from Makefile.in, which should be regenerated by our bleeding-edge
automake script, which is generated by out Makefile -- specifying the
complete chain of dependencies here would bring to a circular dependency
issue.
For this reason, before testing or deploying a change, we are often
forced to perform a full re-bootstrap of the Automake package, to ensure
all our files are actually up-to-date. Until now, this has to be done
manually, thus causing wasted keystrokes and more possibilities of error.
With this change, we introduce a new 'bootstrap' make target to
automatize all the (easy) steps of this re-bootstrapping (plus some
minor bells & whistles since we are at it).
* GNUmakefile: Rewrite to allow an easy bootstrapping and clean rebuild
of the whole package, in particular with the help of ...
(bootstrap): ... this new target.
automake, aclocal: update copyright year in output
Fixes automake bug#11356.
* aclocal.in, automake.in: Add copyright year '2012' in the version
message. Ditto for the copyright notice in the generated Makefile.in
or aclocal.m4 files; and for those, since we are at it, prefer using
a range for copyright years, rather than listing each copyright year
individually.
maint: don't use "union" merge driver for NEWS anymore
The use of the "union" merge driver to avoid conflicts in NEWS has
proven to be problematic, as it often silently produced mis-merges
(instead of spurious conflicts, but a spurious conflict is better
than a mis-merge). Also, our new branching policy (see automake
bug#11153 for a description) should greatly mitigate the problem of
merge conflicts in NEWS. For further discussion, see:
<http://lists.gnu.org/archive/html/automake-patches/2012-04/msg00148.html>
The autogenerated makefile fragment 't/testsuite-part.am' used to depend
on the list of *all* the hand-written files. This was technically correct,
since that makefile fragment was (and still is) generated by the script
'gen-testsuite-part', which scans all the hand-written files to detect
implicit dependencies and to decide for which tests a further wrapper test
should be generated.
However, the presence of such a dependency implied that, whenever *any*
test case was modified (no matter how slightly), the 't/testsuite-part.am'
file was rebuilt, and since that is included by our 'Makefile.am', the
'Makefile.in' file was rebuilt as well by automake. In order to do so,
automake scanned our 'configure.ac' file, which requires the latest
Autoconf version (2.69 at the time of writing), and the casual user can
easily lack that on his machine (and that should be allowed, as automake
currently supports any autoconf version >= 2.62).
The described situation could hinder in-field testing or debugging by
users (even experienced ones) that are not automake developers; see for
example automake bug#11347.
So we drop the explicit dependency of 't/testsuite-part.am' on the
hand-written test cases. (As an aside, note that this has already
been done in Automake-NG, albeit for other reasons; see the commit
'v1.11b-129-g1690aca' of 2012-04-23, "[ng] build: define $(TESTS)
through a wildcard").
This is not a serious regression in the faithfulness of the Automake
build systems, since it unfortunately already had several undeclared
dependencies; e.g., 'Makefile.in' should depend on the automake script,
and 'aclocal.m4' should depend on the aclocal script (but this isn't
possible, as it would mean that distributed files depend on ones generated
at make time). Similarly, 'Makefile.in' should depend on some of the
'lib/am/*.am' files, but does not.
Currently, the workaround to get a faithful and correct rebuild is to run
./bootstrap && ./config.status --recheck && make clean all
and the present commit does not change that.
* Makefile.am ($(srcdir)/t/testsuite-part.am): Don't depend on
't/list-of-tests.mk' nor on '$(handwritten_TESTS)' anymore.
($(generated_TESTS)): Likewise, and don't depend on 'Makefile.am'
either.
The <cstdio> header from Xcode-4.3.2 on Mac OS X 10.7.3 declares a 'isatty'
function with C++ linkage, that conflicts with our dummy definition of the
same function, which in turn is required to work around the absence of the
unistd.h header on MinGW (see commit 'v1.11-2138-gfeea090' of 11-04-2012).
So we tweak the affected tests to work around this new problem as well.
This fixes automake bug#11345.
* t/lex-clean-cxx.sh ($required): Since we are at it, add an explicit
'c++' requirement.
* t/lex-depend-cxx.sh ($required): Likewise.
(my-hdr.hxx): Don't include <cstdio>. The "using namespace" directive
should still be enough to ensure the content of this header is not valid
C, albeit being of course valid C++.
Fix unrelated typos in comments.
(joe.ll): Adjust, by removing the call to 'printf'.
* THANKS: Add entry for reporter "Adam Mercer".
It is only from version 2.69 that the 'AC_PROG_FC' macro has started to
set the '$GFC' variable to "yes" if the selected Fortran compiler is a
GNU compiler. Since we use this variable in our configure.ac, we better
require autoconf 2.69 explicitly.
build: don't require minimal automake version in AM_INIT_AUTOMAKE
* configure.ac (AM_INIT_AUTOMAKE): Don't explicitly require a minimal
automake version number. Since the Automake build system is only meant
to work with the bleeding-edge automake, that requirement was redundant
and misleading.
* configure.ac (AC_INIT): Bump version number to 1.12.
* NEWS: Likewise.
* m4/amversion.m4 (AM_AUTOMAKE_VERSION): Likewise (autoupdated
by ./bootstrap).
coverage: test the internal $(am__relativize) variable
This new coverage might turn out be useful for the planned changes
in Automake-NG. Even if it eventually doesn't, we gen an improved
testsuite exposure of some non-trivial internals, so it's always a
win for us.
* t/relativize.tap: New test.
* t/list-of-tests.mk: Add it.
On at least OpenSUSE 12.1, "make install" will install libraries in
the '${prefix}/lib64' directory by default. This is due to the
$CONFIG_SITE set by /etc/profile.d/site.sh, which sets a libdir
that ends in '/lib64' rather than '/lib' if it finds that the compiler
is generating 64-bit code. This behaviour was causing some spurious
failures in our testsuite. Fix them.
* t/posixsubst-libraries.sh: Assume the libraries are installed in
'$(libdir)' rather than in '$(prefix)/lib'.
* t/posixsubst-ltlibraries.sh: Likewise.
* t/posixsubst-scripts.sh: Similarly, don't assume that '$(bindir)',
'$(sbindir)' and '$(libexedir)' always defaults to respectively
'$(prefix)/bin', '$(prefix)/sbin' and '$(prefix)/libexec'.
* t/transform3.test: Likewise.
* t/lex-libobj.sh: We used to pass LEXLIB='-L /lib' to the ./configure
invocation, to prevent it from explicitly searching for a "lex library".
But the linker on MacOS X 10.5 apparently chokes on that:
cc -g -O2 -o foo foo.o -L /lib yywrap.o
ld: file not found: /lib
collect2: ld returned 1 exit status
So, we now instead pass LEXLIB=' ', which being non-empty is enough
to prevent the search of a "lex library". And since we are at it,
enhance comments on this non-obvious usage.
Co-authored-by: Bruno Haible <bruno@clisp.org> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
vala: configure exit with status 77, not 1, if valac version is too old
From a report by Bruno Haible in automake bug#1193. This change should
also automatically avoid spurious testsuite failures with older vala
versions.
* m4/vala.m4 (AM_PROG_VALAC): Exit with status 77, rather than 1, if
the Vala compiler found older than the minimal required version (if
any). This is more consistent with what is done by other macros like
AM_PROG_UPC or AC_PROG_CC.
* NEWS: Update.
* t/vala-headers.sh: Adjust, so that the test is only skipped of the
vala compiler is too old or the required PKG_CHECK_MODULES third-party
macro is not found by aclocal, and not if a generic error happens in
the configure script.
* t/vala-libs.sh: Likewise.
* t/vala2.sh: Likewise.
* t/vala3.sh: Likewise.
* t/vala5.sh: Likewise.
* t/vala-vpath.sh: Likewise (but don't check for the potential error
with PKG_CHECK_MODULES, as that macro is not used in any way here).
* t/vala4.sh: Adjust, to avoid the new semantic causing this test to
skip instead of failing.
This is a pure refactoring, with no intended functional or semantic
changes. It breaks up an overly-long function in three smaller
sub-functions. This change will very especially useful for the work
on Automake-NG.
* lib/Automake/Rule.pm (define): Move quite a lot of code out, into ...
(_rule_defn_with_exeext_awareness, _maybe_warn_about_duplicated_target,
_conditionals_for_rule): ... these new subroutines.
automake: refactor pre-processing of makefile fragments
This change will provide the automake script with a new function that
reads in a Makefile fragment *without* performing Automake ad-hoc parsing,
but only the pre-processing step, i.e., removal of '##' comments and
substitution of tokens like '%SUBDIRS%', '%?LIBTOOL%' or '?GENENRIC?'.
This will very likely be useful for the work on Automake-NG.
This is a pure refactoring, with no intended functional or semantic
changes.
* automake.in (preprocess_file): New function, extracted ...
(make_paragraphs): ... from here.
Autoconf 2.13 is definitely obsolete today, so giving hints or caveats
about it in the Automake documentation is not only obsolescent, but
also counter-productive, as it suggests that autoconf 2.13 is still
relevant.
* doc/automake.texi: Adjust. Related rewordings. Since we are at it,
prefer using a more modern autoconf version number (2.68 instead of 2.57)
in an example showing how to correctly use 'AC_PREREQ' in third-party
.m4 files.
tests: fix spurious failure with non-ANSI terminals
* t/ax/tap-summary-aux.sh: When checking colored testsuite output,
be sure to export the TERM variable to the value "ansi"; otherwise
the automake testsuite driver will not display colored output, not
even if AM_COLOR_TESTS is exported to "always". Failure revealed
by NixOS Hydra.
* configure.ac (AC_INIT): Bump version number to 1.11e, as per
HACKING suggestion.
* NEWS: Likewise.
* m4/amversion.m4: Likewise (autoupdated by ./bootstrap).
* t/aclocal-install-fail.sh: Do not set the 'errexit' shell flag,
as it is already set by './defs'.
* t/aclocal-install-mkdir.sh: Likewise.
* t/aclocal-no-install-no-mkdir.sh: Likewise.
* t/aclocal-verbose-install.sh: Likewise.
* t/instdir-no-empty.sh: Likewise.
* t/link_cond.sh: Likewise.
* t/python-pr10995.sh: Likewise.
* t/vala-vapi.sh: Likewise.
tests: avoid spurious failures when cross-compiling
* t/parallel-tests-recheck-depends-on-all.sh: Skip the test
when cross-compiling.
* t/vala-vapi.sh: Skip tests that do not make sense when
cross-compiling.
* t/yacc-basic.sh: Likewise.
* t/yacc-cxx.sh: Likewise.
* syntax-checks.mk (ams): The previous change 'v1.11b-36-g127adfb' solved
one problem in the definition of this variable, but also caused it contain
the names of all the left-behind 't/*.dir' temporary test directories.
Fix that.
* syntax-checks.mk (ams): The definition of this variable was invoking
the 'find' utility in an incorrect way, which resulted into the variable
being empty, thus reducing coverage in some maintainer check and making
other hang. Fix this.
When a developer experience one or more failures in the testsuite, a good
workflow is for him to modify its program's sources to fix the bug thus
revealed, run "make recheck" to verify that the change has indeed solved
the testsuite failures previously experienced, and then run "make check"
to verify that the change has not introduced any new failure or regression.
Unfortunately, this apparently natural workflow couldn't have worked until
now, since the Automake-provided 'recheck' target (which didn't depend on
'all') wouldn't have causes the program to be recompiled, and the failed
tests would have thus been run with the older, buggy version of the
program, failing the same way as before.
* lib/am/check.am (recheck): Depend on 'all'.
* t/parallel-tests-recheck-depends-on-all.sh: New test.
* t/list-of-tests.mk: Add it.
* NEWS: Update.
automake: fix botched call to 'check_user_variables'
* automake.in (lang_vala_finish_target): The 'check_user_variables' function
takes an array, not an array ref, as argument; adjust its call accordingly.
* t/vala-headers.sh: New test, checking use of 'valac' options for
header generation (e.g., '-H', '--vapi', ...) in '$(..._VALAFLAGS)'.
* t/list-of-tests.mk: Add it.
* t/vala4.sh: Don't run 'libtoolize', it's not truly required.
($required): Don't require 'libtoolize'.
(configure.ac): Don't invoke 'AC_PROG_LIBTOOL'.
* t/vala-mix.sh ($required): Require 'cc'.
Avoid some calls to 'framework_failure_', they were only useful when
this test was xfailing (to ensure it wasn't failing for the wrong
reasons).
Ensure the stamp file is created in the source directory.
Jim Meyering [Sun, 15 Apr 2012 16:44:50 +0000 (18:44 +0200)]
build: use latest help2man, but without locale support
* doc/help2man: Update to latest (1.40.8), but built with
--disable-nls, which elides the less-portable locale-related
code, and with the "use 5.008" manually changed to "use 5.006".
Thanks to Brendan O'Dea for the tips.
* THANKS: Update Brendan's address.
Jim Meyering [Fri, 13 Apr 2012 15:58:04 +0000 (17:58 +0200)]
build: use slightly older help2man, for improved portability
Fixes automake bug#11235
* doc/help2man: Downgrade to help2man-1.36.4, so that it does
not require Locale/gettext.pm, which is not available on a
default Fedora 16 installation. Reported by Stefano Lattarini.
install: shell parameter expansions can be used in directory names
Fixes automake bug#11232.
GNU automake used to support shell parameter expansion and command
substitutions in installation directories, but that was inadvertently
broken by commit v1.11-759-g368f1c4 "install: don't create empty dirs
when an empty 'foo_PRIMARY' is used" of 18-03-2012, where shell quoting
of generated MKDIR_P command was changed from double to single quotes
in 3 places, while some 21 other places still use double quotes for
generated MKDIR_P commands.
* lib/am/data.am: Use double quotes for generated "mkdir -p" commands.
* lib/am/libs.am: Likewise.
* lib/am/ltlib.am: Likewise.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
* defs (SH_LOG_COMPILER, SH_LOG_COMPILE, SH_LOG_FLAGS,
AM_SH_LOG_FLAGS, SH_LOG_DRIVER, SH_LOG_DRIVER_FLAGS,
AM_SH_LOG_DRIVER_FLAGS): Unset these variable to avoid
potential interferences from the environment.
test defs: unset 'AM_UPDATE_INFO_DIR' environment variable
* defs (AM_UPDATE_INFO_DIR): Unset, to be sure to avoid unduly
interferences from the environment. See also automake bug#11204.
* THANKS: Add entry for David Fang.
Jim Meyering [Thu, 12 Apr 2012 13:07:19 +0000 (15:07 +0200)]
build: generate doc/*.1 files; include help2man
This change is required to avoid making a distributed file depend
on a generated (non-distributed) one. The preceding change
introduced one such dependency, with the distributed doc/*.1
depending on the generated aclocal and automake files. Here,
we avoid the problem by generating the doc/*.1 files rather than
distributing them.
* doc/help2man: New file, version 1.37.1.
* Makefile.am (EXTRA_DIST): Add doc/help2man.
(man1_MANS): Rename from $(dist_man1_MANS). Remove $(srcdir) prefix.
(CLEANFILES): Add these files here, rather than to
$(MAINTAINERCLEANFILES), since we are no longer distributing them.
(update_mans): Use doc/help2man, not $(HELP2MAN).
* configure.ac: Don't test for help2man, now that we bundle it.
Jim Meyering [Wed, 11 Apr 2012 19:25:48 +0000 (21:25 +0200)]
build: avoid parallel build failures
A parallel build would fail when two concurrent sub-make processes
tried to build lib/Automake/Config.pm. The loser would complain that
grep: lib/Automake/Config.pm-t: No such file or directory
chmod: cannot access `lib/Automake/Config.pm-t': No such file or\
directory
make[1]: *** [lib/Automake/Config.pm] Error 1
* Makefile.am (update_mans): Don't build lib/Automake/Config.pm here.
Instead, depend on it from the two rules that use it:
($(srcdir)/doc/aclocal-$(APIVERSION).1): Depend on it.
($(srcdir)/doc/automake-$(APIVERSION).1): Likewise.
[ Note that technically, the above is incorrect, since it makes those
distributed doc/*.1 files depend on generated aclocal and automake.
That problem is addressed by the following commit. ]
However, that was not enough, since even then, a parallel build
would still fail, now with this:
help2man: can't get `--help' info from automake-1.11a
Try `--no-discard-stderr' if option outputs to stderr
make: *** [doc/automake-1.11a.1] Error 1
a subsequent "make -j3" would create the missing file.
That was because help2man would invoke t/wrap/aclocal.in and
t/wrap/automake.in, each of which would require aclocal and
automake, yet those two files weren't guaranteed to be created.
Add explicit dependencies:
($(srcdir)/doc/aclocal-$(APIVERSION).1): Depend on aclocal.
($(srcdir)/doc/automake-$(APIVERSION).1): Depend on automake.
news: remove older entry for "future backward incompatibilities"
* NEWS (New in 1.11.4): Remove subsection about "Future backward
incompatibilities"; they are now either documented changes for the
upcoming 1.12 release, or re-casted as planned future backward
incompatibilities for the next 1.13 release.
* automake.in (lang_vala_finish_target): Return early if the
current '_SOURCES' variable does not contain any '.vala' nor
'.vapi' source. Otherwise, the vala compiler will be called
without arguments, causing an error.
* tests/vala-mix.test: Enhance to catch the fixed bug.
Issue introduced in commit 'v1.11-696-g51f61df' of 27-02-2012,
"vala: fix 'valac' calls for projects with mixed Vala/C", which
fixed automake bug#10894.
* automake.in (lang_vala_finish_target): Also recognize '.vapi'
as an extension for vala input files.
* tests/list-of-tests.mk (XFAIL_TESTS): Remove 'vala-vapi.test'.
self checks: avoid spurious failures when keep_testdirs=yes
* t/self-check-cleanup.tap, t/self-check-dir.tap: Unset the
'keep_testdirs' environment variable, to avoid spurious errors
when the testsuite is run with "keep_testdirs=yes make check".
* t/self-check-cleanup.tap: This test contained several buglets
introduced in the recent row of commits that converted the Automake
build system to a non-recursive setup. Fix them. Since we are at
it, enhance the test to cover also the use of the 'keep_testdirs'
environment variable in order to keep the temporary test directories
around.
Some maintainer checks were too greedy in processing 'Makefile.am'
files, looking for them even in temporary directories left behind
by the test cases, thus causing occasional spurious failures.
* syntax-checks.mk (ams): Ignore 'Makefile.am' files in the
temporary test directories.
The 'sc_tests_makefile_variable_order' maintainer check is too
strict sometimes, blaming automake for outputting out-of-order
variables when this is in fact due to the result of post-processing
of third-party tools or custom test code.
* t/tap-doc2.sh: Ensure the final Makefile.in (that we hack by
hand) is removed, to avoid a spurious maintainer-check failure.
* t/gettext-macros.sh: Ensure that any leftover Makefile.in (that
is generated by gettext/autopoint) is removed, to avoid a spurious
maintainer-check failure.
* HACKING (Release procedure): Do not state that the result of
"make fetch" is woefully incomplete: this is not true anymore today.
Suggest to re-run the testsuite after a "make fetch", in case any
file has been updated.
* syntax-check.mk (sc_mkinstalldirs): Now the 'mkinstalldirs' is
listed in the top-level 'Makefile.am', not in 'lib/Makefile.am';
adjust the "whitelist" accordingly.
(sc_ensure_testsuite_has_run): The 'test-suite.log' file created by
"make check" is now placed in the top-level directory, not in the
't/' subdirectory. Adjust by using '$(TEST_SUITE_LOG)' instead of
an hand-crafted path for the 'test-suite.log' file.
* configure.ac (AC_INIT): Bump version number to 1.11c, as per
HACKING suggestion.
* NEWS: Likewise.
* m4/amversion.m4: Likewise (autoupdated by ./bootstrap).
vala tests: avoid spurious failure with older GObject
* t/vala2.sh: In the 'PKG_CHECK_MODULES' call in 'configure.ac',
don't require gobject >= 2.10, but just >= 2.4: that is enough in
order for the test to pass.
* t/vala3.sh: Likewise.
* t/vala5.sh: Likewise. Also, skip the test instead of failing
if the ./configure invocation fails: that is likely due to the
fact that the GObject library is too old or missing, and that is
not automake's fault.
vala tests: force the use of automatic dependency tracking
* t/vala-mix2.sh: Invoke ./configure with the option
'--enable-dependency-tracking', so that slower dependency
extractors are not rejected. This avoids a spurious failure
at least on Solaris when the Sun C compiler is used.
tests: avoid spurious failures in tests on C++ and lex
This is a follow-up to commit v1.11-2128-g7f2bc63 of 09-04-2012,
"tests: avoid spurious failures with non-flex 'lex' programs and
C++". It is required to avoid a couple of spurious failures on
Solaris and NetBSD systems (at least). See also automake bug#11185.
* t/lex-clean-cxx.sh (parsefoo.lxx): Do not declared the provided
dummy 'isatty' function as 'static', since that might conflict with
a declaration of it as 'extern' pulled in through other system
* t/lex-depend-cxx.sh (joe.ll): Likewise.
* t/README: Update advice, to avoid similar issues in the future.
* rmch:
maint: simplify generation of files with @substed@ stuff
t/README: update w.r.t. recent overhaul (non-recursive build system)
docs: fix names of relevant test cases in comments
NEWS: automake build systems avoids make recursion
maint: no more make recursion in Automake's build system
tests: rename 'tests/' => 't/', '*.test' => '*.sh'
tests: remove recipes that run tests with 'prove'
tests: move most helper scripts and files into the 'ax' subdirectory
tests: avoid spurious failures with non-flex 'lex' programs and C++
This change fixes automake bug#11185.
The commit v1.11-2058-g6f4b08d of 06-03-2012, "tests: explicitly
state that our lexers do not require unistd.h" has broken the tests
'lex-clean-cxx.test' and 'lex-depend-cxx.test' on Solaris, where lex
is not flex and does not understand the "%option never-interactive"
directive. Remove the use of this directive, resorting to defining
a dummy 'isatty()' function instead to keep the flex-generated tests
able to compile also on MinGW/MSYS.
* tests/lex-clean-cxx.test (parsefoo.lxx): Define a dummy 'isatty()'
function.
* tests/lex-depend-cxx.test (joe.ll): Likewise.
* tests/README: Adjust. Fix an unrelated typo since we are at it.
Co-authored-by: Peter Rosin <peda@lysator.liu.se> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
tests: avoid a spurious failures for shells with busted 'set -e'
Some versions of the BSD Korn shell wrongly bail out when the
'errexit' shell flag is active and the left-hand command in a
"&&" list fails and that list is the *last* command of the body
of a "while" or "for" loop.
* tests/install-info-dir.test: Work around that behaviour.
maint: simplify generation of files with @substed@ stuff
Use a proper "config.status --file=-" idiom to do most substitutions
in our generated files, to avoid too much duplications between the
various $(do_subst) commands in Makefile.am and the (explicit or
implicit AC_SUBST) invocation in configure.ac.
From a suggestion by Eric Blake and Federico Simoncelli:
<http://lists.gnu.org/archive/html/automake/2012-01/msg00011.html>
* Makefile.am (do_subst): Rewrite to take advantage of the
"config.status --file=-" idiom.
(generated_file_finalize): New, to help checking that generated
files don't contain unexpanded '@substitutions@', and are made
read-only.
(automake, aclocal): Take advantage of the improved $(do_subst).
Improve comments.
(lib/Automake/Config.pm): Likewise, and of the new variable
$(generated_file_finalize) as well.
($(top_srcdir)/m4/amversion.m4): Likewise.
(defs-static): Likewise, and depend explicitly on 'Makefile'.
(do_subst_t): Remove as obsolete.
* THANKS: Update.
projects / thirdparty / automake.git / log
