* 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
* fix-part-pr13832:
tests: avoid possible autotools caching issues (automake bug#13832)
* fix-pr13760:
dry-run: don't get confused by '-I' option
dry-run: with GNU make, prefer $(MFLAGS) over $(MAKEFLAGS)
header vars: can determine whether we are running under GNU make
* fix-doc-pr14019:
docs: issues with configure substitutions in TESTS
* news-wording-improve:
NEWS: improve wording for automake bug#13514 fix
docs: issues with configure substitutions in TESTS
Motivated by automake bug#14019.
* doc/automake.texi: Currently, when the parallel test harness is in use,
configure substitutions in TESTS definitions can only work if they expand
to tests that ends with a suffix listed in TEST_EXTENSIONS. Document this
limitation.
Fixes automake bug#13760 for non-GNU make implementations that still
support the option '-I'. So far, the only such make implementation
are FreeBSD (8.x) make and NetBSD (5.x) make.
* lib/am/header-vars.am (am__make_dryrun): If a non-GNU make is being
used, try to handle the '-I' option in $MAKEFLAGS correctly. For GNU
make, that is already done by the proper use of the $MFLAGS variable.
dry-run: with GNU make, prefer $(MFLAGS) over $(MAKEFLAGS)
Fixes automake bug#13760 for GNU make.
* lib/am/header-vars.am (am__make_dryrun): If GNU make is being used, rely
on the contents of the $(MFLAGS) variable rather than of the $(MAKEFLAGS)
to decide whther make is being executed in "dry run" mode. Not only this
makes the code possibly faster and less brittle, but also fixes automake
bug#13760 (at least when GNU make is in use).
* t/make-dryrun.tap: Adjust: some tests that were xfailing now pass.
header vars: can determine whether we are running under GNU make
This is mostly a preparatory patch in view of future changes.
* lib/am/header-vars.am (am__is_gnu_make): New, contains shell code that
determines whether we are running under GNU make.
* t/make-is-gnu.sh: New test.
* t/list-of-tests.mk: Add it.
automake: refactoring: factor out common cpp-like flags
* automake.in (@cpplike_flags): In this new variable...
(C, C++, Objective C, Objective C++, Unified Parallel C, Preprocessed
Assembler, Preprocessed Fortran, Preprocessed Fortran 77): ... to be
used by registration (with the 'register_language' subroutine) of these
languages.
This is a refactoring meant to simplify future changes; no semantic
change is intended.
* t/preproc-errmsg.sh: Here, breaking up a sed command to avoid spuriously
triggering a failure in the 'sc_tests_logs_duplicate_prefixes' maintainer
check.
perl: perl subroutine prototypes are problematic, don't use them
Basically, in perl, "subroutine prototypes" are not prototypes at all;
rather, they are a trick to allow user-defined subroutines that behave
like perl built-in functions. For example, prototyped subroutines can
be called without parentheses, and can impose context on their arguments.
Such semantics can be useful in some selected situations, but might also
easily cause unexpected and harmful behaviours and side effects if we
try to use perl prototypes as we would use C prototypes.
See the excellent article "Far More than Everything You've Ever Wanted
to Know about Prototypes in Perl" by Tom Christiansen for more detailed
information:
It is important to note that modern perl allows a non-predeclared
subroutine to be called without the '&' character, as long as its
call uses proper parentheses:
foo 'str', 2; # will trigger errors if foo is not predeclared
foo('str', 2); # ok even if foo is not predeclared
&foo('str', 2); # ditto; but the '&' is old-style and redundant
Note also that the prototype indicating "no argument":
sub func() { ... }
can actually be useful, and has no discernible downsides, so we'll
keep using it where it makes sense.
Also, in few, selected cases, we *want* to have subroutines behave like
perl builtins (e.g., we want the 'append_exeext' function to be able
to take a code block as first argument). In such cases, we will of
course continue to make use of perl subroutine prototypes.
Let's finally see an example that might clarify the kind of problems the
use of subroutine prototypes in perl can cause. This is just scratching
the surface; there are several other aspects, typically subtler and more
dangerous, that are not touched here.
If you have the prototyped subroutine definition:
sub foo ($@)
{
my $s = shift;
print "SCALAR: $s\n";
print "ARRAY: @_\n";
}
and call 'foo' in code like:
@list = (-1, 0, 1);
foo(@list);
you won't get a compile-time nor a runtime error (as a naive interpretation
of the "prototype" characterization would let you think). Rather, the
prototype will cause the array '@list' will be coerced into scalar context
before being passed too 'foo', which means that its *length* (3) will be
passed to 'foo' as first argument; and since no further arguments are
present after '@list', that *void* will be coerced to an empty list before
being passed to 'foo'.
So code above will have the result of printing:
SCALAR: 3
ARRAY:
Quite tricky, and definitely a behaviour we don't want to rely on.
* automake.in: Delete most subroutine prototypes. Fix few of the
remaining ones. Related minor simplifications and adjustments.
* lib/gen-perl-protos: Adjust.
* 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
Pavel Raiskup [Mon, 11 Feb 2013 12:11:51 +0000 (13:11 +0100)]
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>
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'.
* perl-sub-protos:
style: call perl functions 'like_this()', not '&like_this()'
maint: use more perl subroutines prototypes in the automake script
build: auto-generate perl subroutines prototypes for automake and aclocal
refactor: rip module Automake::Language out of automake script
* 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
* t/preproc-demo.sh: New test, a "demo" of how the new pre-processing
feature could be used in a real-world package.
* t/preproc-errmsg.sh: New test, check that error messages remain
useful when the new pre-processing features are involved.
* t/preproc-reldir.sh: Split up ...
* t/preproc-basics.sh, t/preproc-c-compile.sh: ... into these two
tests, with some refactorings, clean-up and enhancements.
* t/list-of-tests.mk: Adjust.
Peter Rosin [Fri, 8 Feb 2013 08:11:45 +0000 (09:11 +0100)]
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.
tests on TAP: don't run the driver with perl unconditionally
* t/ax/tap-setup.sh: When a 'Makefile.am' was pre-existent in the
test directory at the moment the client test script sourced this
file, said 'Makefile.am' was tweaked to provide it with a proper
definition of TEST_LOG_DRIVER. However, there was an error in this
automatic definition, since it caused the TAP test driver to be
unconditionally invoked with perl. This wasn't an issue in most
situations, since perl is smart enough to re-execute a given script
with the proper interpreter if it sees a she-bang line that doesn't
seem to point to perl itself. Still, there is no reason to do
something blatantly wrong even if our tools correct the dumb mistake
for us. So fix the TEST_LOG_DRIVER definition.
maint: use more perl subroutines prototypes in the automake script
* automake.in: Throughout this file. Note that these new prototypes
are not much useful, since many subroutine calls still use the old
'&foo' form; but we'll take care of that in later patches.
* lib/Automake/Language.pm (target_hook): Call the '_target_hook'
of the given language in a more modern form, avoiding '&'.
build: auto-generate perl subroutines prototypes for automake and aclocal
This will allow us to avoid either using the '&foo' invocation form when
invoking a subroutine before its definition, or having to maintain the
list of prototypes by hand (with the risk of having it become incomplete
or fall out-of-sync when future edits to the automake and aclocal scripts
are done).
* Makefile.am (automake, aclocal): Automatically generate a list of
prototypes by looking at the subroutines definitions.
* bootstrap.sh: Likewise, when generating the temporary automake and
aclocal scripts used for bootstrapping.
* automake.in: Add a placeholder that will be tracked by the new recipes
and substituted with the computed prototypes. Remove existing prototypes,
that are now superfluous. Some adjustments required by the new, more
comprehensive prototypes declarations.
* aclocal.in: Likewise.
* maintainer/syntax-checks.mk (sc_diff_automake, sc_diff_aclocal): Adjust.
refactor: rip module Automake::Language out of automake script
This is just a preparatory patch in view of future changes.
* lib/Automake/Language.pm: New module, ripped out from ...
* automake.in: ... here. Related adjustments.
* Makefile.am (dist_perllib_DATA): List the new module.
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.
* 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)
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.
* 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
* doc/automake.texi (The Types of Distributions): Here,
cross-reference "List of Automake options" rather then
the more generic node "Options". Improve wording while
at it.
The 1.13.2 bug-fixing release will ship from the 'branch-1.13.2' git
branch, not from the 'maint' one, since the latter contains changes
that are non-trivial and hasn't cooked enough yet. The 'maint' branch
will give rise to the 1.13.3 release instead, eventually. Adjust the
version number to match.
* configure.ac (AC_INIT): Bump version number to 1.13.2b.
* m4/amversion.m4: Likewise (auto-updated by "make bootstrap").
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
Thien-Thi Nguyen [Mon, 21 Jan 2013 12:35:03 +0000 (13:35 +0100)]
tests: avoid a spurious failure when running inside Emacs
Some versions of Emacs set the environment variable 'EMACS' to 't'
for child processes. Thus, when running from inside Emacs, "$(MAKE) -e"
erroneously allows the 't' to override the one in the Makefile.
* t/lisp-flags.sh: Unset var 'EMACS', fixing the issue.
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:
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):
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.
docs: serial-tests are not deprecated, just discouraged
We don't plan to remove support for them, nor to have the serial-tests
option give any kind of runtime warning, so don't alarm the users
still using serial tests with pointless "deprecation" or "obsolescence"
warnings.
Fixes automake bug#13478.
See also:
<http://lists.gnu.org/archive/html/automake/2013-01/msg00058.html>
init.m4: add probe to check "rm -f" without args work
See automake bug#10828.
POSIX will say in a future version that running "rm -f" with no argument
is OK: <http://austingroupbugs.net/view.php?id=542>).
We want to be able to make that assumption in our Makefile recipes.
So we introduce an aggressive probe to check that the usage we want is
actually supported "in the wild" to an acceptable degree.
* m4/init.m4 (AM_INIT_AUTOMAKE): Implement the probe. To make any issue
more visible, cause the running configure to be aborted by default if
the 'rm' program in use doesn't match our expectations; the user can
still override this though, by setting the ACCEPT_INFERIOR_RM_PROGRAM
environment variable to "yes".
* t/spy-rm.tap: Update heading comments.
* t/rm-f-probe.sh: New test.
* t/list-of-tests.mk: Add it.
* PLANS/rm-f-without-args.txt: Adjust.
Since the next major automake version will make the behaviour so far
only activated with the 'subdir-object' option mandatory, it's better
if we start warning users not using that option.
As suggested by Peter Johansson, we strive to avoid the warning when
it would be irrelevant, i.e., if all source files sit in "current"
directory.
Mike Frysinger [Sat, 12 Jan 2013 05:19:40 +0000 (00:19 -0500)]
ithreads: use runtime (not configure time) detection of perl threads
I can't imagine the runtime checks being a big runtime penalty, so there
shouldn't be a need to do the checks at configure check and hardcode the
result in the generated automake.
With the current system, it means if you change your perl config (build
perl w/threads, build automake, build perl w/out threads), or deploy a
compiled automake package on a different system (build had threads, but
deployed system does not), you get errors when trying to run automake.
So take the logic from configure.ac and move it to the one place where
PERL_THREADS is used (lib/Automake/Config.in) and do the version/config
checking at runtime.
* bootstrap.sh (PERL_THREADS): Delete assignment and use in sed.
* configure.ac (am_cv_prog_PERL_ithreads, PERL_THREADS): Delete all code
related to these two variables.
* lib/Automake/Config.in (perl_threads): Initialize to 0, and only set to
1 if the perl version is at least 5.007_002, and useithreads is in Config.
Copyright-paperwork-exempt: yes Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
projects / thirdparty / automake.git / log
