| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This update has been made with 'make update-copyright'.
|
| |
|
|
| |
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
| |
We've been in 2014 already for few months now...
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some shells (e.g., Solaris 10 /bin/ksh, or NetBSD 5.1 /bin/sh),
"unset VAR" returns a non-zero exit status in case the VAR variable
is already unset. This doesn't interact well with our usage of
"set -e" in the testsuite. So far, we've avoided spurious failures
by either explicitly ignoring the exit status from unset:
unset VAR || :
or explicitly ensuring that a variable is set, before trying to
unset it:
VAR=; unset VAR
But we can do better, by aliasing the 'unset' command to a custom
function that will take care of these details for us. This will
avoid us annoying spurious failures in the future, failures that
have already bitten us too much times. For an example, refer to
commit 'v1.12.2-88-g5b1dae5' of 2012-08-05 (tests: avoid tons of
spurious failures on NetBSD).
* t/ax/test-lib.sh (_am_unset): New function.
(unset): New alias to it.
(_am_exit): Adjust comments.
* t/ax/am-test-lib.sh: No need to temporary disable the 'errexit'
shell flag when unsetting variables that are potentially already
unset.
(am_process_requirements): Adjust to remove a now-useless
workaround related to unset.
* t/aclocal-macrodir.tap: Likewise.
* t/aclocal-macrodirs.tap: Likewise.
* t/auxdir-autodetect.sh: Likewise.
* t/ax/am-test-lib.sh: Likewise.
* t/ax/test-lib.sh: Likewise.
* t/check-tests-in-builddir.sh: Likewise.
* t/dist-formats.tap: Likewise.
* t/distcheck-configure-flags-am.sh: Likewise.
* t/distcheck-configure-flags.sh: Likewise.
* t/java-empty-classpath.sh: Likewise.
* t/javaflags.sh: Likewise.
* t/lflags.sh: Likewise.
* t/lflags2.sh: Likewise.
* t/lisp-flags.sh: Likewise.
* t/lisp6.sh: Likewise.
* t/missing-auxfile-stops-makefiles-creation.sh: Likewise.
* t/parallel-am.sh: Likewise.
* t/parallel-am2.sh: Likewise.
* t/parallel-am3.sh: Likewise.
* t/parallel-tests-log-override-recheck.sh: Likewise.
* t/pkg-config-macros.sh: Likewise.
* t/python-missing.sh: Likewise.
* t/python-too-old.sh: Likewise.
* t/python11.sh: Likewise.
* t/self-check-dir.tap: Likewise.
* t/self-check-report.sh: Likewise.
* t/self-check-seq.tap: Likewise.
* t/silent-configsite.sh: Likewise.
* t/suffix6c.sh: Likewise.
* t/tar-override.sh: Likewise.
* t/tests-environment-and-log-compiler.sh: Likewise.
* t/vala-configure.sh: Likewise.
* t/werror3.sh: Likewise.
* t/yflags-cmdline-override.sh: Likewise.
* t/yflags.sh: Likewise.
* t/yflags2.sh: Likewise.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It gives the impression that they are directly runnable, as with
"./t/foo.sh", but it has been a while since that was the case. Today,
tests are runnable only through "make check" or "./runtest".
This change is for the 'micro' branch (automake 1.13.2a). It will
soon be followed by similar patches for the 'maint' branch (automake
1.13a) and the 'master' branch (automake 1.99a).
* t/*.sh, t/*.tap: Remove executable bit.
* maint.mk (sc_tests_executable): Remove.
(syntax_check_rules): Adjust.
* gen-testsuite-part: Set permissions of generated tests to
'444' (-r--r--r--), rather than 555 (-r-xr-xr-x).
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |\
| |
| |
| |
| |
| | |
* fix-pr13514:
aclocal: fix for more-than-once specified directories
aclocal: just warn if the primary local m4 dir doesn't exist (don't error)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Related to automake bug#13514.
Do not consider directories for extra m4 files multiple times in
'aclocal'. Doing so caused problems on older packages that specify
configure.ac: AC_CONFIG_MACRO_DIRS([m4])
Makefile.am: ACLOCAL_AMFLAGS = -I m4
if the 'm4' directory does not exist when aclocal is called the first
time by autoreconf.
See:
<http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html>
* aclocal.in (scan_m4_files): Remove duplicates in @user_includes.
* t/aclocal-macrodir.tap: Extend.
* t/aclocal-macrodirs.tap: Likewise.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See discussion about automake bug#13578 for more details and background.
Basically, for the versioning scheme:
- micro versions only for bug and regression fixing;
- minor versions for new backward-compatible features, and new
non-fatal deprecations;
- major versions for backward-incompatibilities, complex new
features, and major refactoring.
And for the git branching scheme:
+ branch 'next' is for the upcoming major version;
+ branch 'master' is now for the upcoming minor version;
+ branch 'maint' is for the upcoming micro (bug-fixing) version;
+ the merging hierarchy is: 'maint' -> 'master' -> 'next'.
* HACKING (Automake versioning and compatibility scheme): New.
(Working with git): Adjust.
* NEWS: Update and fix.
* aclocal.in: Adjust some "FIXME" messages.
* automake.in: Likewise.
* m4/mkdirp.m4: Likewise.
* t/aclocal-acdir.sh: Likewise.
* t/aclocal-macrodir.tap: Likewise.
* t/aclocal-macrodirs.tap: Likewise.
* lib/Automake/Options.pm: Likewise.
* m4/internal/ac-config-macro-dirs.m4: Likewise.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
| |
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When "older" version of autoconf are used (that is, those before commit
v2.69-44-g1ed0548), we have no sane way to prevent the autom4te invocation
issued from aclocal to possibly display warnings "MACRO m4_require'd but
not m4_defun'd". That's not a big deal, because that just means that
people using pre-2.70 autoconf with cutting-edge automake will see few
spurious warnings, but the actual semantics will remain correct.
However, this blemish was causing a couple of annoying testsuite failures.
Solve this by simply skipping the affected tests when older (pre-2.70)
autoconf versions are used.
* t/aclocl-macrodir.tap ("AC_CONFIG_MACRO_DIR interaction with
AC_REQUIRE"): Skip when older autoconf is in use.
* t/aclocl-macrodirs.tap ("AC_CONFIG_MACRO_DIR interaction with
AC_REQUIRE"): Likewise.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When some macro expanded in configure.ac calls AC_REQUIRE on another
macro that is defined in one of the local m4 macro dirs specified
with AC_CONFIG_MACRO_DIRS, aclocal prints spurious warnings like:
configure.ac:4: warning: MY_BAR is m4_require'd but not m4_defun'd
configure.ac:3: MY_FOO is expanded from...
Such warnings come from autom4te, and are due to the fact that the
*first* autom4te invocation issued by aclocal is not yet able to
"see" the m4 macro definitions in the local m4 dirs (because they
can be looked for only after the AC_CONFIG_MACRO_DIRS call has been
traced, and tracing it requires running autom4te).
To allow us to work around this issue, autom4te has introduced a new
"witness" macro 'm4_require_silent_probe', that, when defined, allows
us to silence that particular kind of warnings (and only it).
Reported by Nick Bowler; see point (4) of:
<http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00000.html>
* aclocal.in (trace_used_macros): Pre-define the special macro
'm4_require_silent_probe' when invoking autom4te.
* t/aclocal-macrodirs.tap ("AC_CONFIG_MACRO_DIR interaction with
AC_REQUIRE"): This test passes now: remove the "TODO" directive.
* t/aclocal-macrodir.tap ("AC_CONFIG_MACRO_DIRS interaction with
AC_REQUIRE"): Likewise.
* t/acloca17.sh: Remove.
* t/list-of-tests.mk: Adjust.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When some macro expanded in configure.ac calls AC_REQUIRE on another
macro that is defined in one of the local m4 macro dirs specified
with one of the macros AC_CONFIG_MACRO_DIRS or AC_CONFIG_MACRO_DIR,
aclocal prints spurious warnings like:
configure.ac:4: warning: MY_BAR is m4_require'd but not m4_defun'd
configure.ac:3: MY_FOO is expanded from...
Expose this weakness in our testsuite.
Reported by Nick Bowler; see point (4) of:
<http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00000.html>
* t/aclocal-macrodir.tap ("AC_CONFIG_MACRO_DIR interaction with
AC_REQUIRE"): New test, still xfailing.
* t/aclocal-macrodirs.tap ("AC_CONFIG_MACRO_DIRS interaction with
AC_REQUIRE"): Likewise.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new implementation ensures that any directory (possibly excluding
the first one, if the '--install' option is used) that is declared with
AC_CONFIG_MACRO_DIRS and that is non-existent will cause an error from
aclocal.
* aclocal.in (scan_m4_dirs): Add a new argument, telling whether it's OK
for the scanned directory to be non-existing. Adjust the implementation
accordingly.
($first_user_m4dir): Remove, no more needed.
(scan_m4_files): Update 'scan_m4_dirs' invocations so that aclocal will
not complain if the first user macro directory is non-existing and the
'--install' option is given: such directory will be created later by
aclocal itself.
* t/aclocal-macrodir.tap: Do not mark the last test as TODO anymore;
it now passes. Make stricter by ensuring a non-existing directory in
AC_CONFIG_MACRO_DIRS causes an hard error, not a warning.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new macro 'AC_CONFIG_MACRO_DIRS' has been recently introduced in
autoconf (and is expected to appear in the autoconf 2.70 release),
allowing us to declare several local m4 macro directories for a
package.
It can be done either passing several arguments to a single invocation:
AC_CONFIG_MACRO_DIRS([dir1 dir2])
or issuing more invocations:
AC_CONFIG_MACRO_DIRS([dir1])
AC_CONFIG_MACRO_DIRS([dir2])
or a combination of the two:
AC_CONFIG_MACRO_DIRS([dir1 dir2])
AC_CONFIG_MACRO_DIRS([dir3])
This will allow projects to use several m4 macro local dirs, without the
need to use ACLOCAL_AMFLAGS (which we want to make obsolete and finally
remove). This is especially important for projects that are used as
nested subpackages of larger projects.
For more information and rationales, refer to these past discussions:
<http://lists.gnu.org/archive/html/autoconf/2011-12/msg00037.html>
<http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00010.html>
<http://lists.gnu.org/archive/html/autoconf-patches/2012-07/msg00000.html>
<http://lists.gnu.org/archive/html/autoconf-patches/2012-07/msg00012.html>
<http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/8037/>
<http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/8087>
<http://thread.gmane.org/gmane.comp.sysutils.automake.patches/8956>
as well as to Automake commit v1.12.1-165-gcd1a9cc of 2012-07-03,
"aclocal: deprecate ACLOCAL_AMFLAGS, trace AC_CONFIG_MACRO_DIR instead",
autoconf commit v2.69-42-gd73770f of 2012-10-17, "AC_CONFIG_MACRO_DIRS:
new macro, mostly for aclocal".
* aclocal.in ($ac_config_macro_dir): Turn this global scalar it into ...
(@ac_config_macro_dirs): ... this global array.
(trace_used_macros): Update '@ac_config_macro_dirs' instead of
re-defining '$ac_config_macro_dir'. Cater to calls the now-preferred
macro 'AC_CONFIG_MACRO_DIRS' in addition to the "obsolescent" one
AC_CONFIG_MACRO_DIR.
(main loop): Append '@ac_config_macro_dirs', not '$ac_config_macro_dir',
to '@user_includes'.
* t/subpkg-macrodir.sh: New test.
* t/aclocal-macrodirs.tap: Likewise.
* t/list-of-tests.mk: Add them.
* t/aclocal-macrodir.tap: Adjust and extend a little to keep it more in
sync with 'aclocal-macrodirs.tap'.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to today's commit v1.12.4-22-g0610fc8,
"tests: prepare to move ./defs to t/ax/test-init.sh"
* All tests: To run the common setup, use the command:
. test-init.sh
instead of the older, "historical" one:
. ./defs || exit 1
Note that the "|| exit 1" wasn't really useful, since the 'errexit'
shell flag is in effect in both './defs' and 'test-init.sh', and all
the known shells that are good enough to run the automake testsuite
do automatically exit with error when a sourced file cannot be found
(at least, they do so in non-interactive mode, which is the only
mode that concerns us in the testsuite).
* t/ax/tap-summary-aux.sh, t/ax/testsuite-summary-checks.sh: Likewise.
* gen-testsuite-part: Do the same in the generated tests.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
| |
|
|
| |
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
Maintaining ACLOCAL_AMFLAGS in the Makefile.am to pass extra flags
to aclocal is (and have always been) quite of an hack. For example,
autoreconf is forced to grep Makefile.am to honour those flags. But
this is a bad obsolescent behaviour; in fact, the autotools have moved
consistently in the past years from custom grepping of Makefile.am and
configure.ac to tracing of m4 macro calls, which is more consistent,
more reliable and more flexible.
And when autoreconf is not used, the developer is forced to add *by hand*
the flags specified by ACLOCAL_AMFLAGS to the aclocal calls not triggered
by make rebuild rules; here lie again more duplication and more chances
for errors.
Moreover, ACLOCAL_AMFLAGS has only two typical use cases:
- to instruct aclocal to look for extra macro definition in a local
directory (as with "ACLOCAL_AMFLAGS = -I m4"); and
- to further instruct aclocal to copy in that local directory the
required third-party .m4 files found in the system-wide directory
(as with "ACLOCAL_AMFLAGS = -I m4 --install").
The first use case can be better covered if aclocal can instead trace and
honours call to the AC_CONFIG_MACRO_DIR autoconf macro; and the second
use case shouldn't be considered really legitimate, as it is quite (and
subtly) brittle (see automake bug#9037).
Thus we now make aclocal trace AC_CONFIG_MACRO_DIR macro, and act
accordingly. For backward compatibility, we continue to support the
ACLOCAL_AMFLAGS special variable (although removing any mention of it
from the documentation). Future Automake releases will likely start
to warn about the use of that variable, and eventually remove support
for it altogether.
From a suggestion by Eric Blake.
This is a much simplified (and IMHO saner) version of the patch series
discussed in the threads:
<http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00045.html>
<http://lists.gnu.org/archive/html/automake-patches/2010-12/msg00156.html>
* aclocal.in ($ac_config_macro_dir): New global variable.
(trace_used_macros): Also trace the macro 'AC_CONFIG_MACRO_DIR',
and set the '$ac_config_macro_dir' variable accordingly.
(parse_arguments): Code for diagnosis of '--install' used without
any user-specified include directory moved ...
(while (1)): .. into the main loop. Which now also updates the
list of user-specified include directories to include the directory
given as argument to the call (if any) of 'AC_CONFIG_MACRO_DIR'.
* lib/am/configure.am: Update comments.
* NEWS: Updated.
* doc/automake.texi: Likewise. Also, stop advising the use of the
'--install' in ACLOCAL_AMFLAGS (see automake bug#9037 for a rationale),
and remove any reference to ACLOCAL_AMFLAGS (which is now considered
obsolescent).
* t/aclocal-path-install.sh: Adjust grepping check in the aclocal
error messages.
* t/subpkg.sh: Updated: add 'AC_CONFIG_MACRO_DIR' call to configure.ac,
remove setting of 'ACLOCAL_AMFLAGS' in Makefile.am and use of aclocal
command line arguments.
* t/subpkg2.sh: Likewise.
* t/subdir8.sh: Likewise.
* t/remake10c.sh: Likewise.
* t/remake8a.sh: Likewise.
* t/remake8b.sh: Likewise.
* t/aclocal4.sh: Likewise.
* t/aclocal6.sh: Likewise.
* t/acloca14.sh: Likewise.
* t/acloca22.sh: Likewise.
* t/aclocal5.sh: Likewise, and do not not invade the Automake
namespace (this avoids spurious failures).
* t/acloca14b.sh: New test, identical to the previous version of
'acloca14.test'; it is kept to verify backwards compatibility with
the use of ACLOCAL_AMFLAGS.
* t/acloca22b.sh: Likewise (but for 'acloca22.test').
* t/aclocal-amflags.sh: New test, check for backwards
compatibility that ACLOCAL_AMFLAGS still works.
* t/remake-macrodir.sh: New test, checking that aclocal's honoring of
AC_CONFIG_MACRO_DIR interacts nicely with automatic rebuild rules.
* t/list-of-tests.mk: Add the new tests.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
