[ng] internals: copy 'header-vars.am' more verbatim in the output makefile
* automake.in (define_standard_variables): The 'header-vars.am' file should
contain no rule definition, nor any variable definition that must be known
at automake runtime; so we can read and process that file's content using
the 'preprocess_file' function rather than the 'file_contents_internal' one.
This will allow us to make a more liberal use of GNU make builtins in there,
like the 'define' builtin.
* t/comment4.sh: Adjust.
* t/vpath.sh: Likewise.
* t/txinfo17.sh (texinfo.texi): Use "foobar", not "example", as the
argument of the @setfilename call, to ensure we don't get false
positives in the later grepping checks.
In GNU make, '$^' used in a recipe contains every dependency for the
target, even those not declared when the recipe is read; for example,
on:
all: foo1; @echo $^
all: foo2
"make all" would output "foo1 foo2". This is not Automake's fault,
as some comments incorrectly stated. See also:
<http://lists.gnu.org/archive/html/help-make/2012-05/msg00029.html>
* lib/am/texinfos.am: Fix those incorrect comments, and document the
GNU make behaviour described above.
* t/suffix-custom-link.sh: Rewrite a little to avoid triggering warnings
from the 'sc_tests_here_document_format' maintainer check.
* syntax-checks.mk (sc_diff_aclocal_in_aclocal,
sc_diff_automake_in_automake): Rename ...
(sc_diff_aclocal_in_aclocal,
sc_diff_automake_in_automake): ... respectively to these, rewrite to use
static pattern rules and 'diff -u' instead of bare 'diff', and fix the
count of expected differences to account for the removed substitution of
'@SHELL@' in automake.in.
(syntax_check_rules): Adjust.
* master: (21 commits)
news: document deprecation of configure.in
news: put planned backward compatibilities early
sync: update files from upstream with "make fetch"
maint: deprecate 'configure.in' as autoconf input
maint: post-release minor version bump
release: stable release 1.12.1
copyright: update copyright years in a couple of files
tests: avoid spurious failures with Solaris 9 cscope program
maintcheck: fix a spurious failure
perf: beginning of a performance testsuite
aclocal: declare function prototypes, do not use '&' in function calls
news: support for configure.in will be dropped in future automake versions
missing: support AC_CONFIG_HEADERS in addition to obsolete AC_CONFIG_HEADER
missing: don't bother checking for AM_CONFIG_HEADER: it is gone now
docs: remove mention of AM_CONFIG_HEADER: it is obsolete and removed now
tests: fix botched heading comments in 'lex-clean-cxx.sh'
[ng] maintcheck: some tweaks and fixlets
help: fix a typo in the list of warning categories
maint: version bump after beta release
release: beta release 1.12.0b (will become 1.12.1)
...
+ Extra non-trivial edits:
* Makefile.am (TESTS): Add the tests in the 't/perf' directory.
* maint:
news: document deprecation of configure.in
news: put planned backward compatibilities early
sync: update files from upstream with "make fetch"
maint: deprecate 'configure.in' as autoconf input
maint: post-release minor version bump
release: stable release 1.12.1
copyright: update copyright years in a couple of files
tests: avoid spurious failures with Solaris 9 cscope program
maintcheck: fix a spurious failure
perf: beginning of a performance testsuite
aclocal: declare function prototypes, do not use '&' in function calls
news: support for configure.in will be dropped in future automake versions
tests: fix botched heading comments in 'lex-clean-cxx.sh'
[ng] maintcheck: some tweaks and fixlets
help: fix a typo in the list of warning categories
maint: version bump after beta release
release: beta release 1.12.0b (will become 1.12.1)
release: remove overly picky check
[ng] vars: recognize escaped '#' correctly in a variable definition
Regression revealed by a failure in test 't/backslash-tricks.sh', and
caused by the recent merge of the 'ng/var-simplify' branch.
It is worth noting that this change has a collateral effect: comments
placed after the variable definition *must* now be separated with one
or more spaces from said definition:
# This won't work, and will produce a subtly broken Makefile
foo = val# comment
foo += val2
# Please do this instead
foo = val # comment
foo += val2
We believe that supporting the use of escaped '#' characters in variable
definitions is more important than supporting the fringe case above.
* lib/Automake/VarDef.pm (raw_value): Fix processing of stored value
to account for escaped '#' characters.
(value): Add a FIXME comment about a statement that is not strictly
true anymore now that we assume GNU make.
* t/backslash-tricks.sh: Extend a bit.
* t/comment8.sh: Relax a bit, by placing spaces between the variable's
definitions and the comments on the same line. Extend in another
respect, to watch against a regression introduced by the first draft of
this commit.
* NEWS (Warnings and deprecations): We now warn if 'configure.in' is
used instead of 'configure.ac' as autoconf input.
(Future backward-incompatibilities): Adjust.
It has been years since that has been deprecated in the documentation,
in favour of 'configure.ac':
Previous versions of Autoconf promoted the name configure.in, which
is somewhat ambiguous (the tool needed to process this file is not
described by its extension), and introduces a slight confusion with
config.h.in and so on (for which '.in' means "to be processed by
configure"). Using configure.ac is now preferred.
It's now time to start giving runtime warning about the use of
'configure.in', so that support for it can be removed in future
versions of autoconf/automake.
See also, in the Autoconf repository, commit 'v2.69-4-g560f16b' of
2012-05-23, "general: deprecate 'configure.in' as autoconf input".
* lib/Automake/Configure_ac.pm: Issue a warning in the 'obsolete'
category if 'configure.in' is detected. Since this module is synced
from Automake, this change is to be backported there (and will be
soon).
* t/help.sh: Adjust.
* t/configure.sh: Adjust and enhance.
tests: avoid spurious failures with Solaris 9 cscope program
* t/cscope.tap: Also check that the cscope program in use supports the
'-q' option; if this is not the case, some cscope usages in the generated
Makefiles would fail, so we must skip the checks involving those usages.
* ng/var-simplify:
[ng] cosmetics: avoid redundant use of '&' in subroutine calls
[ng] rename: define_pretty_variable -> define_cond_variable()
[ng] cleanup: prefer 'define_variable' over 'define_pretty_variable'
[ng] refactor: change signature of 'define_variable()'
[ng] vars: get rid of VAR_ASIS / VAR_PRETTY distinction
[ng] vars: keep track of conditionals in appended values and comments
[ng] vars: simplify logic for appending conditionally
[ng] VarDef: store comments and values as a perl array
[ng] refactor: support comments only for VarDef, not for ItemDef too
[ng] tests: Automake should let us append to undefined variables (someday)
[ng] tests: spy behaviour of '+=' with GNU make
[ng] vars: get rid of VAR_SILENT type
[ng] vars: get rid of VAR_SORTED type
[ng] cleanup: remove unused private variables in Automake::Variable
[ng] vars: get rid of VAR_ASIS / VAR_PRETTY distinction
It doesn't offer us any real advantage (apart from some eye-candy
in the generated makefile), and complicates the code and the
internal APIs.
* automake.in (define_verbose_var, define_configure_variable,
file_contents_internal): Adjust the 'Automake::Variable::define'
call to drop the VAR_ASIS parameter.
(define_pretty_variable): Likewise. Also, adjust the function
description not to state that the value of a variable defined by
it is "pretty printed in the output file".
(handle_subdirs): Don't try to prettify the RECURSIVE_TARGETS
variable anymore.
(read_am_file): Adjust the 'Automake::Variable::define' calls
to drop the VAR_ASIS parameter. Also, don't "prettify" the
definition of variables whose value is more than 1000 characters
long. That is now done directly ...
* lib/Automake/Variable.pm (output): ... in here.
(define): Drop the '$pretty' parameter, and adjust implementation
details accordingly. Now output variable definitions are only
prettified when needed, i.e., when their value is more than 1000
characters long. And the only reason this prettification is done
is to ensure the generated Makefile.in won't have lines so long
that could confuse tools (like sed and awk) processing it into a
Makefile at config.status runtime.
(Pod Documentation): Adjust.
(_has_line_too_long): New internal function.
(transform_variable_recursively): Drop '$pretty' parameter in a
call to 'define'.
* lib/Automake/VarDef.pm (VAR_ASIS, VAR_PRETTY): Delete.
(@EXPORT): Don't advertise them.
(new): Don't take nor store the '$pretty' parameter anymore.
(pretty): Remove this accessor method.
(Pod Documentation): Adjust.
* t/check2.sh: Adjust.
* t/distcom-subdir.sh: Likewise.
* t/distcom2.sh: Likewise.
* t/longline.sh: Likewise.
* t/pluseq3.sh: Likewise.
* t/subdir4.sh: Likewise.
* t/subst-no-trailing-empty-line.sh: Remove as obsolete.
[ng] vars: simplify logic for appending conditionally
This will make the generated Makefiles more bloated, but that should
be OK, since eventually further refactorings will change the format used
to output conditional variables extending, and the resulting Makefiles
will once again be smaller and cleaner.
* lib/Automake/Variable.pm (define): When appending to an existing
variable *defined in another condition*, don't bother to avoid the
creation of intermediate internal variables when that's not really
needed; just create them unconditionally.
(_new): Don't reset $self->{'last-append'} anymore, it has been
removed (it was only used in the 'define' function).
[ng] texinfo: take advantage of GNU make features in several recipes
* lib/am/texibuild.am: In a recipe, use $(@D) instead of extracting
the directory component from '$@' with echo+sed.
* lib/am/texinfos.am (am__create_installdir): New private helper
variable.
Rewrite several rules to take advantage of it and of GNU make automatic
variables (like $^) and builtins (like $(and), $(addprefix), $(notdir)).
Add a workaround for a misfeature of the Automake parser/preprocessor
that might sometimes prevent us from using the '$^' automatic variable
correctly in our recipe.
* lib/am/texinfos.am (uninstall-info-am): Remove support for '*.iNN'
files used on DJGPP.
(maintainer-clean-aminfo): Likewise.
* bootstrap.sh: Adjust comments: we don't use "ln -s" not because
it's not properly supported by DJGPP, but because it might not be
properly supported by MinGW/MSYS.
[ng] general: assume dot-starting file names are supported
Now that we've dropped support for DJGPP, Windows 95/98/ME and MS-DOS,
that should always the case.
* lib/am/texibuild.am: Just assume we can have directories whose name
starts with a dot, i.e., that '${am__leading_dot}' expands to '.'.
* m4/depend.m4 (AM_SET_DEPDIR): Likewise. Now $(DEPDIR) will be set
unconditionally to '.deps'.
* m4/init.m4 (AM_INIT_AUTOMAKE): Don't AC_REQUIRE the m4 macro
'AM_SET_LEADING_DOT' anymore.
* m4/lead-dot.m4: Delete.
* Makefile.am (dist_automake_ac_DATA): Remove it.
* NG-NEWS: Update.
* t/subobj11a.sh: Just assume $(DEPDIR) expands to '.deps'.
[ng] cleanup: drop support for DJGPP, Windows 95/98/ME, MS-DOS
See also:
<http://lists.gnu.org/archive/html/automake-ng/2012-05/msg00104.html>
* automake.in (BEGIN): Don't override $ENV{SHELL} for DJGPP.
* bootstrap: Don't special case the default value for BOOTSTRAP_SHELL
on DJGPP. While we are at, allow that variable to be overridden from
the environment.
* configure.ac (MODIFICATION_DELAY): Define to '2' unconditionally, as
we don't have to cater to quirks of Windows 95/98/ME anymore.
* lib/am/texibuild.am: Remove support for '*.iNN' files used on DJGPP.
* lib/am/texinfos.am: Likewise.
* NG-NEWS: Update.
Now that, after today's commit 'v1.12-331-g645bb21', Automake-NG does
not follow the chain of user-defined pattern rules anymore, there's no
need to treat such rules preferentially, nor to reject old-fashioned
suffix rules. This will help interoperability with tools like Gnulib,
which generated Makefile.am fragments that still uses old-fashioned
suffix rules (since they are targeted to mainline Automake).
* automake.in (handle_footer): Do not reject the '.SUFFIXES:' rule
nor the 'SUFFIXES' variable. Add a "FIXME" comment about why we
still support the 'SUFFIXES' variable.
* lib/Automake/Rule.pm: Do not error out if an old-fashioned suffix
rule is seen.
* lib/am/footer.am (.SUFFIXES): Depend on '$(SUFFIXES)', if that's
non-empty.
* t/suffix-rules-reject.sh: Remove.
* t/suffix-rules-old-fashioned.sh: New.
* NG-NEWS: Adjust.
* doc/automake-ng.texi (Suffixes): Do not state that Automake-NG
rejects attempts to define old-fashioned suffix rules.
[ng] compile: rename make variable DEFAULT_INCLUDES -> AM_DEFAULT_INCLUDES
The automake-generated variable 'DEFAULT_INCLUDES' has never been
documented, and it violates user namespace. So rename it to
'AM_DEFAULT_INCLUDES', to make it clear that it is owned by Automake.
We prefer that name to something that would sound more "private",
like 'am__default_includes', because there are possibly legitimate
usages of that variable on the user's part.
* automake.in, lib/am/compile.am: Do the rename.
* NG-NEWS, doc/automake-ng.texi: Update.
* t/confh4.sh, t/no-extra-makefile-code.sh: Adjust.
* syntax-checks.mk (old_vars_checks): Add new check
'sc_no_DEFAULT_INCLUDES'.
(modern_DEFAULT_INCLUDES): Define to 'DEFAULT_INCLUDES'.
[ng] compile: add extra -I opts from config headers at make runtime
Unless the 'no-stdinc' option is in use, automake automatically adds
to the compiler's include path (through the use of '-I' options placed
in the $(DEFAULT_INCLUDES) variable) the $(srcdir), the current
directory, and all the directories where header files specified with
AC_CONFIG_HEADERS macro are placed. It also tries to remove unseemly
duplicated '-I' entries, for example simplifying "-I. -I$(srcdir)" to
"-I." when in a non-VPATH build (in which case '$(srcdir)' is simply
'.').
Before this change, that preprocessing was done both at automake runtime
and configure runtime; with GNU make features, we can simplify it a bit
and move almost all of it at make runtime instead.
* automake.in (handle_compile): Remove automake-time preprocessing, and
support for further configure-time preprocessing, of the intended contents
of $(DEFAULT_INCLUDES); instead, move all of them ...
* lib/am/compile.am (DEFAULT_INCLUDES) [%?STDINC%]: ... here.
* m4/init.m4: Remove AC_SUBST of @am__isrc@.
* t/no-extra-makefile-code.sh: Trivially adjust.
* t/nostdinc.sh: Adjust by preferring more "semantic" checks to grepping
checks.
* t/confh4.sh: Adjust and extend.
* t/stdinc-no-repeated.sh: New test.
* Makefile.am (do_subst): Remove a now-unneeded hack.
[ng] compile: rename make variable CONFIG_HEADER -> AM_CONFIG_HEADERS
The automake-generated variable 'CONFIG_HEADER' has never been
documented, and it violates user namespace. So rename it to
'AM_CONFIG_HEADERS', to make it clear that it is owned by Automake.
We prefer that name to something that would sound more "private",
like 'am__config_headers', because there are possibly legitimate
usages of that variable on the user's part.
* automake.in: Do the rename. Also, don't bother explicitly
rejecting the setting of 'CONFIG_HEADER' as an anachronism:
that warning has been active so long that any still maintained
Makefile.am file should have stopped doing that long ago.
* NG-NEWS: Update.
* lib/am/remake-hdr.am: Update a comment.
* syntax-checks.mk (modern.CONFIG_HEADER): New, define to
'AM_CONFIG_HEADERS'.
[ng] maintcheck: refactor checks on obsolete variable names
This is just a preparatory refactoring, to make future additions
easier.
* syntax-checks.mk (sc_renamed_variables_rules): New autocomputed
variable.
($(sc_renamed_variables_rules)): New static pattern rule, subsuming
most of the existing checks against the use of old names for some
automake provided make variables.
(syntax_check_rules): Add the contents of the new variable, and do
not explicitly list the checks subsumed by it.
[ng] suffix: drop Automake-time chaining of suffix rules
This change simplifies the Automake::Rule module a little, moves yet
more logic from Automake runtime to GNU make runtime (in the spirit of
Automake-NG), and gets us rid of some never-documented nor completely
specified Automake magics. OTOH, it also breaks some idioms that, while
only relevant for uncommon cases, have been working since the first
Automake releases. Still, it is easy to slightly modify those idioms to
have the use cases they were catering to correctly handled with the new
semantics (examples of this are given below); the only downside being the
need of a little more verbosity and explicitness on the user's part.
So, with the present change, automake starts using a much simpler and
dumber algorithm to determine how to build an object associated to a
source whose extension in not one of those it handles internally.
The new algorithm goes like this. For any file listed in a '_SOURCES'
variable whose suffix is not recognized internally by automake (in
contrast to known suffixes like '.c' or '.f90'), automake will obtain
the expected target object file by stripping the suffix from the source
file, and appending either '.$(OBJEXT)' or '.lo' to it (which one depends
on whether the object is built as part of a program, a static library, or
a libtool library). It will then be assumed (but not checked!) that the
user has defined a rule (either explicit or defined from a pattern rule)
which can turn that source file into this corresponding object file. For
example, on an input like:
automake will expect that the three objects 'mu.$(OBJEXT)', 'fu.$(OBJEXT)'
and 'zu.$(OBJEXT)' are to be used in the linking of the 'foo' program, and
that the user has provided proper recipes for all those objects to be
built at make time, as well as a link command for linking 'foo'. Here is
an example of how those declarations could look like:
%.$(OBJEXT): %.ext1
my-compiler -c -o $@ $<
# We need to compile mu with debugging enabled.
mu.$(OBJEXT): mu.ext1
my-compiler -DDEBUG=1 -c -o $@ $<
foo_LINK = $(CC) -o $@
In this particular case, the idiom above is basically the same one that
would be required in mainline automake (apart for the fact that, there,
old-fashioned suffix rules should be used instead of pattern rules). To
see what is truly changed with the new algorithm, we have to look at a
more indirect usage.
Mainline Automake follows the chain of user-defined pattern rules to
determine how to build the object file deriving from a source file with
a custom user extension; for example, upon reading:
automake knew that it has to bring in the C++ support (compilation rules,
requirement for AC_PROG_CXX in configure.ac, etc), and use the C++ linker
to link the 'foo' executable.
But after the present change, automake *won't follow those implicit
chains of pattern rules* anymore; so that the idiom above will have to
be re-worked like follows to preserve its intent and behaviour:
%.cc: %.zoo:
$(preprocess) $< > $@
bin_PROGRAMS = foo
# The use of '.cc' is required to let Automake know to bring in
# stuff for the handling of C++ compilation, and to use the C++
# linker to build 'foo'.
nodist_foo_SOURCES = bar.cc
EXTRA_DIST = foo.zoo
Finally, we must note another, slightly annoying first consequence of
this change of semantics: one can't use anymore "header files" with
extensions unrecognized to Automake anymore; for example, an usage like
this:
# Won't work anymore: will cause errors at make runtime.
%.h: %.my-hdr
$(preprocess-header) $< >$@
foo_SOURCES = foo.c bar.my-hdr
BUILT_SOURCES = bar.h
will cause the generated Makefile to die on "make all", with an error
like:
make[1]: *** No rule to make target 'bar.o', needed by 'zardoz'. Stop.
while an usage like this:
# Won't work anymore: will cause errors at automake runtime.
%.h: %.my-hdr
$(preprocess-header) $< >$@
foo_SOURCES = foo.c foo.my-hdr
BUILT_SOURCES = foo.h
will cause automake itself to die, reporting an error like:
object 'foo.$(OBJEXT)' created by 'foo.my-hdr' and 'foo.c'
We don't believe the above breakage is a real issue though, because
the use case can still be served by placing the "non standard" headers
in EXTRA_DIST rather than in a _SOURCES variable:
# This will work.
%.h: %.my-hdr
$(preprocess-header) $< >$@
foo_SOURCES = foo.c
EXTRA_DIST = foo.my-hdr
BUILT_SOURCES = foo.h
A more detailed list of changes follow ...
* automake.in (register_language): Don't call 'register_suffix_rule'
on the source and object extensions of the registered languages.
(handle_single_transform): Implement the new simple algorithm described
in details above (plus an hack to continue supporting Vala-related
'.vapi' files in _SOURCES variables). Remove the only call ever to ...
(derive_suffix): ... this function, which has thus been removed.
* lib/Automake/Rule.pm
($_suffix_rules_default, $suffix_rules, register_suffix_rule): Remove.
(@EXPORT, reset): Adjust.
(define): Don't call 'register_suffix_rule' on the suffixes of target
and dependency when a pattern rule is seen.
* t/specflg10.sh: Move ...
* t/am-default-source-ext.sh: ... to this more proper name, and
adjusted.
* t/suffix12.sh: Renamed ...
* t/suffix-custom-subobj.sh: ... to this, and remove a botched heading
comment.
* t/suffix3.sh: Adjust.
* t/suffix5.sh: Likewise.
* t/suffix8.sh: Likewise.
* t/suffix10.sh: Likewise.
* t/suffix13.sh: Likewise.
* t/suffix-chain.sh: Likewise.
* t/suffix-hdr.sh: Likewise.
* t/suffix-custom.sh: New test.
* t/suffix-custom-link.sh: Likewise.
* t/suffix-custom-default-ext.sh: Likewise.
* t/yacc-lex-cxx-alone.sh: Likewise.
* NG-NEWS: Update.
Some tests in the Automake testsuite already aims only at verifying
the performance, rather than the correctness, of some operations.
Still, they are somewhat shoehorned and forced into the PASS/FAIL
framework (say, with the 'ulimit' shell builtin used to verify some
operation doesn't take up too much time or memory), but that is
conceptually a stretch, and has already caused problems in practice
(see automake bug#11512 for an example).
So we start moving the "performance tests" out of the testsuite proper,
and make them run only "on demand" (when the user exports the variable
'AM_TESTSUITE_PERF' to "yes"). Ideally, we should provide those tests
with a custom runner/driver that measures and displays the relevant
performance information, but doing that correctly and with the right
APIs is definitely more difficult, so we leave it for a later step
(an hope we'll take such a step eventually).
* t/cond29.sh: Move ...
* t/perf/cond.sh: ... here, and adjust.
* t/testsuite-recheck-speed.sh: Move ...
* t/perf/testsuite-recheck.sh: ... here.
* t/testsuite-summary-speed.sh: Move ...
* t/perf/testsuite-summary.sh: ... here.
* t/list-of-tests.mk (perf_TESTS): New variable, listing the tests in
the 't/perf' directory.
(handwritten_TESTS): Adjust.
* defs: Skip any tests in the 't/perf/' subdirectory unless the
'AM_TESTSUITE_PERF' variable is set to "yes" or "y".
* .gitignore: Update.
aclocal: declare function prototypes, do not use '&' in function calls
This change will also fix automake bug#11543 (from a report by Matt
Burgess).
* aclocal.in: Declare prototypes for almost all functions early, before
any actual function definition (but omit the prototype for the dynamically
generated '&search' function). Add prototypes to any function definition.
Remove '&' from function invocations (i.e., simply use "func(ARGS..)"
instead of "&func(ARGS...)").
* THANKS, NEWS: Update.
news: support for configure.in will be dropped in future automake versions
The use of configure.in as Autoconf input has been deprecated for a
very long time in the Autoconf documentation, and the next version of
Autoconf (2.70) will start warning about it ar runtime as well (see
commit 'v2.69-4-g560f16b' or 2012-05-23, "general: deprecate
'configure.in' as autoconf input", in the Autoconf's git repository).
missing: support AC_CONFIG_HEADERS in addition to obsolete AC_CONFIG_HEADER
* missing (autoheader*): Do not look only for AC_CONFIG_HEADER when
grepping configure.ac, but also for AC_CONFIG_HEADERS: the latter has
been preferred to the former by several years now in Autoconf.
missing: don't bother checking for AM_CONFIG_HEADER: it is gone now
* missing (autoheader*): Do not look for AM_CONFIG_HEADER when
grepping configure.ac: it is not supported anymore (has been in
fact deleted in commit v1.12-15-gd2ca168 of 2012-04-27, "m4: delete
several obsolete macros").
Merge branch 'ng/drop-configure-in' into ng/master
* ng/drop-configure-in:
maintcheck: obsolete check 'sc_tests_no_configure_in' removed
cleanup: get rid of 'Automake::Configure_ac' module
cleanup: just assume configure input is configure.ac
cleanup: don't support configure.in anymore
There's no need to verify our tests doesn't use the obsoleted
name 'configure.in' for the Autoconf file anymore: we don't support
it anyway in Automake-NG, so any test trying to use it would fail.
cleanup: get rid of 'Automake::Configure_ac' module
Now that we unconditionally assume the Autoconf input is named
configure.ac, it's easier and clearer to inline the checks on
the existence of such a file directly in the automake and
aclocal scripts.
* automake.in (Automake::Configure_ac): Drop this import.
(Main code): Check the existence of configure.ac directly, instead
of calling the noe-removed 'require_configure_ac' function.
* aclocal.in: Likewise.
cleanup: just assume configure input is configure.ac
We have removed support for configure.in in a previous patch anyway.
* automake.in ($configure_ac): Initialize statically to 'configure.ac'.
* aclocal.in: Likewise.
* lib/Automake/Variable.pm: Likewise. Consequently, ...
(Automake::Configure_ac): ... drop this import, that is not required
anymore.
The autoconf input should be named 'configure.ac' instead. The use
of 'configure.in' has been deprecated in Autoconf since at least
the 2.13 -> 2.50 transition, and future Autoconf versions (starting
with 2.70 probably) will start to warn about it at runtime.
* lib/Automake/Configure_ac.pm (find_configure_ac): Don't look for
configure.in if configure.ac is not found.
(require_configure_ac): On failure, don't tell that "'configure.ac'
or 'configure.in' is required", but just that "'configure.ac' is
required".
* automake.in (@common_sometimes): Don't list 'configure.in'.
(scan_autoconf_files): Adjust heading comments.
* NG-NEWS: Update.
* t/help.sh: Adjust.
* t/configure.sh: Adjust as obsolete.
[ng] build: use more GNU make features in our Makefile.am
Mostly to show that we can do so without upsetting Automake-NG.
* Makefile.am (do_subst): Remove some code duplication through the use of
the $(foreach) builtin, and take advantage of GNU make automatic variables
to require less boilerplate in the callers.
* All its callers: Adjusted.
(EXTRA_DIST): Remove some code duplication through the use of and the
$(addprefix) builtin. Since we are at it, remove some erroneously
duplicated entries (probably resulting from a botched merge).
(bin_SCRIPTS): Rewrite in function of $(AUTOMAKESOURCES), using the
$(basename) builtin.
(man1_MANS): Split contents into ...
(versioned_mans, unversioned_mans): ... these two variables.
(doc/aclocal-$(APIVERSION).1, doc/automake-$(APIVERSION).1): Rewrite
common rules using GNU make static pattern rules.
(automake, aclocal): Likewise.
(installcheck-executable-scripts): Take more advantage of GNU make
builtins in the recipe.
(install-data-hook): Likewise.
(doc/aclocal.1, doc/automake.1): Likewise. Consequently ...
(update_mans): ... remove this variable, now unneeded.
($(top_srcdir)/m4/amversion.m4): Renamed ...
($(srcdir)/m4/amversion.m4): ... to this. Since we are in a non-recursive
setup, $(srcdir) and $(top_srcdir) are the same; and according to the
comments, the use of $(top_srcdir) in this target was only needed to avoid
confusing some non-GNU make implementation.
($(srcdir)/autodeps.am): Fix a typo in the target name, renaming it ...
($(srcdir)/testsuite-autodeps.am): ... to this. Use GNU make automatic
variables to avoid some verbosity in the recipe. And fix a typo in
comments while we are at it.
* syntax-checks.mk (sc_no_brace_variable_expansions): Do not complain
about ${MAKEVAR} usages in comments: they might be legitimate. This
change is not strictly required for mainline automake, but will help
in the Automake-NG branch.
* sc_tests_here_document_format: Relax a bit, so that usages like
"cout << "string" << endl;" in the test scripts (usages which can be
used in here documents defining C++ sources) are not flagged as uses
of bad delimiters for here documents. This change is not strictly
required for mainline automake, but will help in the Automake-NG
branch, and will anyway be more future proof w.r.t. possible future
testsuite additions.
(sc_tests_Exit_not_exit): Do not whitelist lines containing $PERL
explicitly (that was only required for one test); instead ...
* t/ext2.sh: ... use "exit (1)" instead of "exit 1" in the perl
invocation of the guilty script.
On Solaris 10, the parallel testsuite harness could fail with errors
like this when /usr/bin/nawk was the selected awk program.
nawk: next is illegal inside a function at source line 1 in \
function input_error; context is:
function input_error(file) { ... close_current(); next; >>> } <<<
* lib/am/parallel-tests.am (am__create_global_log): In the awk script
defined by this function, avoid use of the 'next' directive inside a
function.
* NG-NEWS: Move the existing entries describing obsolete features that
have been removed out of the section "Miscellaneous" and into a new
section (aptly named "Obsolete Features Removed"). Move an entry
relevant to support for distribution from the section "Miscellanea"
into the section "Distribution". Improve separation of different
sections with more use of vertical spacing.
init: obsolete usages of AM_INIT_AUTOMAKE not supported anymore
This is a follow-up on commit v1.12-66-g27136df of 2012-05-06, "init: warn
against obsolete usage of AM_INIT_AUTOMAKE".
With this change, we drop support for the two-arguments and three-arguments
invocation forms of the AM_INIT_AUTOMAKE macro, as in either of:
AM_INIT_AUTOMAKE($PACKAGE, $VERSION)
AM_INIT_AUTOMAKE($PACKAGE, $VERSION, NODEFINE)
* NEWS, doc/automake.texi: Update.
* m4/init.m4 (AM_INIT_AUTOMAKE): Report the two- and three-arguments
invocation form as a hard error.
* t/aminit-moreargs-deprecation.sh: Renamed ...
* t/aminit-moreargs-deprecation.sh: ... to this, and updated to check
the new semantics.
* t/ac-output-old.tap: Adjust by avoiding old-style uses of AC_INIT
and AM_INIT_AUTOMAKE.
* t/acsilent.sh: Likewise.
* t/dirlist.sh: Likewise.
* t/dirlist2.sh: Likewise.
* t/req.sh: Likewise.
* t/nodef.sh: Remove as obsolete.
* t/version.sh: Likewise.
* t/version2.sh: Likewise.
* t/backcompat.sh: Likewise.
* t/backcompat2.sh: Likewise.
* t/backcompat3.sh: Likewise.
* t/backcompat5.sh: Likewise.
* t/backcompat4.sh: Renamed ...
* t/backcompat-acout.sh: ... to this.
* t/list-of-tests.mk: Adjust.
[ng] tests: fix spurious failure under "make distcheck"
* t/verbatim.sh: This test copied in files from the directory of Automake
internal '.am' fragments, and then overwrote one of them with 'cat >'.
But that is bound to fail under a "make distcheck", because in that case
all of the source directory (in particular the '.am' files in it) are made
read only. This can be fixed by unlinking the file we want to overwrite
before actually writing to it.
[ng] VarDef: store comments and values as a perl array
This is a preparatory refactoring in view of a planned change to
how the definitions of make variables augmented with '+=' are
output in the generated Makefiles.
* t/comments-in-var-def.sh: New xfailing test, shows an example of the
improved semantic for variable definitions/additions we want to reach
eventually.
* Makefile.am (XFAIL_TESTS): Add it.
* lib/Automake/VarDef.pm (new): Store values and comments for the
variable in array references, not in scalars.
(append): Just append the passed value and comment to those arrays,
without preprocessing. The existing preprocessing has been moved ...
(raw_value): ... to this accessor function.
(comment, dump): Adjust.
[ng] refactor: support comments only for VarDef, not for ItemDef too
Comments are actually handled and used for variable definitions only,
so no point in handling it also for rule definitions. And this will
simplify our next step where we change how variable definitions (and
related comments) are stored and displayed.
* lib/Automake/ItemDef.pm (new): Don't take a $comment argument
anymore, and don't set a $self->{comment} field in the returned
object.
(comment): Remove this accessor method.
(Pod documentation): Adjusted.
* lib/Automake/Rule.pm (define): Don't pass a $comment argument
to the Automake::RuleDef constructor anymore. No real loss here,
since we were unconditionally passing an empty comment anyway.
* lib/Automake/RuleDef.pm (new): Don't take a $comment argument
anymore, and don't pass it to the Automake::ItemDef constructor.
(Pod documentation): Adjusted.
* lib/Automake/VarDef.pm (new): Directly store the $comment
argument in the $self->{comment} field. Don't pass the
Automake::ItemDef constructor anymore.
(comment): New accessor method (it is no more inherited from
Automake::ItemDef anymore).
* ng/suffix-simplify:
[ng] rule, lang: get rid of 'suffix_rules_count', simplify logic
[ng] coverage: mixing Fortran and C++
[ng] coverage: pure languages doesn't bring in C support
[ng] rule: get rid of $KNOWN_EXTENSIONS_PATTERN
[ng] coverage: custom pre-processes headers in prog_SOURCES
This new make function is still unused in our codebase, but it's nice
to have it ther,e ready and tested, should the need for it ever arise.
* lib/am/header-vars.am (am__canon): New function.
(am__bslash, am__comma, am__dollar, am__pound, am__lparen, am__rparen,
am__bquote, am__dquote, am__squote ): New immediate variables, used by
the above function to avoid spurious syntax errors (e.g., $(am__comma)
expands to ',', which would be unusable directly in a make function call).
* t/internals.tap: Extend.
tests: don't disable portability warnings when there's no need
Some annoying portability warnings only needed for non-GNU makes have
since long been removed in Automake-NG, so they don't have to be
explicitly disabled in tests that checked "unportable" behaviours.
general: assume '#' comment in make recipes are ok
The Autoconf manual (2.69) reports:
Some make implementations treat anything starting with a tab as
a command for the current rule, even if the tab is immediately
followed by a '#'. The make from Tru64 Unix V5.1 is one of them.
The issue doesn't affect GNU make though, so we can zap another now
redundant automake time check
* automake.in (read_am_file): Don't report rules starting with a
"#" as unportable.
* t/comment3.sh: Remove as obsolete.
* Several tests: In make rules, use '#' comments rather than more
fragile ':' comments; e.g., instead of:
: Processed header files should not be distributed.
test ! -r $(distdir)/one.h
use:
# Processed header files should not be distributed.
test ! -r $(distdir)/one.h
general: assume GNU make semantic in line continuation
The line continuation with a backslash is yet another source of
portability problems for Makefiles.
For example, according to the Autoconf manual, some versions of
make (e.g., HP-UX) read multiple newlines following a backslash,
continuing to the next non-empty line.
Also, according to Posix, make comments start with # and continue
until an unescaped newline is reached; but some BSD make versions
do not follow this requirement.
Finally, some make implementations (like Solaris 10 CCS make)
handle a '\#' sequence at the end of a line like it was a line
continuation:
$ cat Makefile
x = \#
all:; : $(x)
$ /usr/local/bin/gmake
: #
$ /usr/ccs/bin/make -f foo.mk
mksh: Error in reader: Loop detected when expanding macro value `\#
all:; : $(x)'
Current working directory /tmp
Luckily, GNU make is more rational and consistent in its handling
of line continuation, which allows us to drop some Automake time
checks. Not a great simplification, but better than nothing.
* automake.in (read_am_file, file_contents_internal): Don't error
on blank line following trailing backslash, on comment following
trailing backslash, nor on trailing backslash on the last line.
* t/spy-trailing-backslash.sh: New, check that the expected GNU
make semantics actually hold.
* t/backslash-tricks.sh: New test, check that automake truly
supports the uses of backslash it doesn't warn about anymore.
* t/backsl3.sh: Remove as obsolete.
* t/comment5.sh: Likewise.
* t/commen10.sh: Likewise.
* t/commen11.sh: Likewise.
* t/syntax.sh: Likewise.
fixup: support verbatim lines only in private '.am' fragments
We don't want to commit such a blatant hack for public consumption yet.
* automake.in (read_am_file): Don't handle !-escaped lines.
* t/verbatim.sh: Adjust, and, while we are at it, tweak to avoid a
spurious maintainer-check failure.
fixup: interaction between verbatim lines and line continuation
When line continuations were involved, our hack to pass lines verbatim
to the output Makefile didn't work as expected; for example, the input
!$(call foo,=, \
! long continued line still in the call)
produced in the generated Makefile an output like
$(call foo,=, \
! long continued line still in the call)
rather than as the expected
$(call foo,=, \
long continued line still in the call)
That bug severely limited the usefulness of our hack. Luckily, it's
pretty easy to fix.
* automake.in (file_contents_internal): Handling of !-escaped
lines moved ...
(make_paragraphs): ... here, and adjusted to cope with line
continuations.
* lib/am/parallel-tests.am: Break overly long !-escaped lines,
now that we can.
[ng] tests: Automake should let us append to undefined variables (someday)
This is not the case yet, mostly for historical reason. However, allowing
that would mimic the behaviour of GNU make more closely (see the test case
't/spy-var-append.sh'). Likely (and hopefully), it would also simplify
the implementation.
* t/var-undef-append.sh: New test, still failing.
* Makefile.am (XFAIL_TESTS): Add it.
* automake.in (define_configure_variable): in an AC_SUBST'd variable is to
be "ignored" (likely because the user has called 'AM_SUBST_NOTMAKE' on it),
return early without even defining the variable, rather than defining it
with type VAR_SILENT (which would have prevented its definition from being
output in the generated Makefile anyway).
* lib/Automake/VarDef.pm (VAR_SILENT): Delete.
(@EXPORT, Pod documentation): Adjust accordingly.
* lib/Automake/Variable.pm (_check_ambiguous_condition): Don't ignore
variables of type VAR_SILENT: there are no more of them.
(output): Don't skip variables of type VAR_SILENT: there are no more of
them.
(define): The value of the '$pretty' parameter can't be VAR_SILENT anymore.
Adjust internal checks and Pod documentation accordingly.
It's basically unused, and the tiny cosmetic enhancements it offers
are not worth the complication of having yet another variable type.
* automake.in (handle_subdirs): Force RECURSIVE_TARGETS to be of
type "VAR_PRETTY" rather than "VAR_SORTED". This removes the only
actual use of the VAR_SORTED constant.
* lib/Automake/VarDef.pm (VAR_SORTED): Delete.
(@EXPORT, Pod documentation): Adjust accordingly.
* lib/Automake/Variable.pm (output): Don't handle variables of type
VAR_SORTED anymore.
(define): The value of the '$pretty' parameter cannot be VAR_SORTED
anymore. Adjust internal checks and Pod documentation accordingly.
[ng] cleanup: remove unused private variables in Automake::Variable
* lib/Automake/Variable.pm ($_VARIABLE_CHARACTERS, $_VARIABLE_PATTERN,
$_VARIABLE_RECURSIVE_PATTERN): Remove, they have been unneeded and
unused since commit 'v1.11-1779-g9a82dcd' of 2012-01-23, "[ng] vars:
don't warn about non-POSIX names or GNU make function calls".
* ng/check:
[ng] news: update w.r.t. recent changes in testsuite harnesses (TESTS based)
[ng] doc: update w.r.t. recent changes in testsuite harnesses (TESTS-based)
[ng] coverage: parallel-tests and dynamic $(TEST_EXTENSIONS) content
[ng] cosmetics: improve comments and spacing in 'parallel-tests.am'
[ng] check: support conditional $(TEST_EXTENSIONS)
[ng] check: warn about dot-less $(TEST_EXTENSIONS) at make runtime
[ng] check: be laxer in accepted $(TEST_EXTENSIONS)
[ng] check: logic to define *LOG_DRIVER vars moved to generated Makefiles
[ng] warns: don't report possible issues with '_DEPENDENCIES' variables
[ng] refactor: merge check2.am into parallel-tests.am
[ng] am: new make variable '$(am__handle_exeext)'
[ng] check: unconditionally distribute test-driver
[ng] check: warn about invalid TEST_EXTENSIONS at make runtime
[ng] check: separate serial and parallel harnesses in distinct '.am' files
[ng] check: move definition of console colors in its own '.am' fragment
[ng] refactor: make '$am_config_aux_dir' available as a make variable
[ng] am: implement $(am__tolower) and $(am__toupper)
[ng] tests: get rid of an almost-obsolete test case (parallel-tests related)
[ng] serial-tests: simplify automake-time preprocessing
[ng] am: new private make variable $(am__all_progs)
[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.
* 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).
[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.
* 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.
[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).
* NG-NEWS (Parallel testsuite harness): The 'test-driver' auxiliary script
is always distributed when the TESTS variable is seen, even if it is not
strictly required. Conditional and dynamic (even computed at make runtime)
content of TEST_EXTENSIONS is supported. We are more liberal in accepting
TEST_EXTENSIONS entries (it's enough that they start with a dot), and if
any of them is invalid, an error is given at make runtime, not at automake
runtime. Adjust some existing text to be more clear, thanks to a better
use of separating vertical and horizontal space.
[ng] doc: update w.r.t. recent changes in testsuite harnesses (TESTS-based)
* doc/automake-ng.texi (EXEEXT): $(TESTS) and $(XFAIL_TESTS) are not
anymore rewritten for $(EXEEXT) appending, even when the 'serial-tests'
option is in use.
(Parallel Tests Harness): The content of $(TEST_EXTENSIONS) is more
liberally accepted now (any dot-starting string is accepted), and if it
turns out any entry is invalid, an error about that will be reported at
make runtime, not at automake runtime.
* t/test-extensions-funny-chars.sh: Enhance to verify that we can actually
have test extension composed by digits (as is implied by the manual).
[ng] coverage: parallel-tests and dynamic $(TEST_EXTENSIONS) content
The recent changes to the parallel-tests implementation should allow us
to define or override TEST_EXTENSIONS with more dynamic contents; in
particular, something like:
[ng] cosmetics: improve comments and spacing in 'parallel-tests.am'
* lib/am/parallel-tests.am: Fix some comment typos and missing
capitalization; improve clarity through more use of vertical
spacing; add a coupe of explicative comments.
[ng] check: support conditional $(TEST_EXTENSIONS)
That is pretty easy to do with the current code base; just ...
* automake.in (handle_tests): ... stop erroring on conditional contents
of TEST_EXTENSIONS, and move the definitions of a default TEST_EXTENSIONS
variable ...
* lib/am/parallel-tests.am: ... in here.
* t/test-extensions-cond.sh: Rewritten to adapt to the new semantic.
[ng] check: warn about dot-less $(TEST_EXTENSIONS) at make runtime
* lib/am/parallel-tests.am: Analyze the $(TEST_EXTENSIONS) contents at
make runtime, instead of relying on the '%INVALID_TEST_EXTENSIONS%'
transform once passed in by automake. Do any necessary error reporting
with the help of ...
(am__maybe_invalid_test_extensions): ... this new function.
* automake.in (is_valid_test_extension): Delete.
(handle_tests): Don't call that anymore. Simplify accordingly. Rely
on code in parallel-tests.am to report the proper errors at runtime.
* t/test-extensions.sh: Moved ...
* t/test-extensions-invalid.sh: ... to this, nd updated.
* Makefile.am (XFAIL_TESTS): Drop 'test-extensions.sh'.
[ng] check: be laxer in accepted $(TEST_EXTENSIONS)
Relax our checks on the contents of $(TEST_EXTENSIONS) by simply
verifying that every entry there starts with a dot.
The only reasons the restriction on the $(TEST_EXTENSIONS) was in
place was to ensure the relevant LOG_COMPILER, LOG_DRIVER, etc.,
variables derived from an extension had valid names according to
POSIX; but this is overkill for GNU make, since for it variables
names can happily contain "funny" characters as well (e.g., '!',
'@', '-', ...).
Maybe in the future we could start to again complain about truly
problematic characters (like '$', '=' or ','), but let's not
over-engineer for the moment. After all, mainline Automake had
suffered from a similar limitation in the long-lived version 1.11
(until commit v1.11-476-g90bea64 of 2011-10-01, "parallel-tests:
automake error our on invalid TEST_EXTENSIONS"), and nobody had
ever complained.
* automake.in (is_valid_test_extension): Be much laxer: accept
all the strings beginning with a dot, in addition to the @EXEEXT@
substitution.
* t/test-extensions-funny-chars.sh: New test.
[ng] check: logic to define *LOG_DRIVER vars moved to generated Makefiles
If a LOG_DRIVER variable is undefined, we should define a default for it,
pointing to the "simple" test driver ('lib/test-driver' in the automake
repository). Move the logic to do so out of the automake script and into
the generated Makefiles.
* automake.in (handle_per_suffix_test): Remove.
(handle_tests): Don't call it anymore, and simplify accordingly.
* lib/am/parallel-tests.am (am__handle_per_suffix_test): Define the
relevant LOG_DRIVER variable to a proper default if it is undefined.
* t/test-driver-cond.sh: Remove obsolete grepping checks.
[ng] warns: don't report possible issues with '_DEPENDENCIES' variables
This will allow us to move (in future changes) some more processing at
make runtime, without having automake complain spuriously (which couldn't
be avoided, as to avoid such complaints automake should have access to
context and information only available at make runtime -- which is clearly
impossible).
* NG-NEWS: Document that Automake-NG can be weaker than mainline Automake
in diagnostic and early error detection; and also explain why it is so.
* automake.in (check_typos): Don't check for possible typos in the
'_DEPENDENCIES'.
Consequently, don't bother calling 'set_seen' ...
(handle_per_suffix_test): ... on the 'LOG_DEPENDENCIES' variables ...
(scan_aclocal_m4): ... nor on the 'CONFIG_STATUS_DEPENDENCIES' and
'CONFIGURE_DEPENDENCIES' variables ...
(handle_tags): ... nor on the 'TAGS_DEPENDENCIES' variable ...
(handle_ltlibraries): ... nor on the 'libfoo_la_DEPENDENCIES' nor
the 'EXTRA_libfoo_la_DEPENDENCIES' variables ...
(handle_libraries): ... nor on the 'libfoo_a_DEPENDENCIES' nor the
'EXTRA_libfoo_a_DEPENDENCIES' variables ...
(handle_programs): ... nor on the 'program_DEPENDENCIES' nor the
'EXTRA_program_DEPENDENCIES' variables.
* t/vartypos.sh, t/vartypo2.sh: Relax accordingly.
This is just a preparatory commit in view of future changes.
* lib/am/header-vars.am (am__handle_exeext): New internal variable,
defined to "yes" if the automake static conditional '?HANDLE-EXEEXT?'
is true, and to "no" otherwise.
This new behaviour is suboptimal, but will allow us to move yet more
logic and processing from the automake scripts into the generated
Makefiles.
* automake.in (handle_tests): Distribute 'test-driver' unconditionally
if the variable TESTS is defined and the 'serial-tests' option is not
used.
(handle_per_suffix_test): Don't distribute 'test-driver' anymore.
* Several tests: Adjust.
* t/test-driver-custom-no-extra-driver.sh: Remove as obsolete.
[ng] check: warn about invalid TEST_EXTENSIONS at make runtime
* automake.in (handle_tests): Instead of warning about invalid test
extensions at Automake runtime, pass their list through the transform
'%INVALID_TEST_EXTENSIONS%' to ...
* lib/am/parallel-tests.am: ... this file, that will warn at make
runtime if that list is not empty.
[ng] check: move definition of console colors in its own '.am' fragment
This is only meant to simplify future changes. No semantic change is
intended.
* lib/am/check.am: Include ...
* lib/am/check.am (am__tty_colors, am__tty_colors_dummy): Move out to ...
* lib/am/color-tests.am: ... this new file.
* Makefile.am (dist_am_DATA): Adjust.
projects / thirdparty / automake.git / log
