Most of these spelling fixes are just to comments and documentation.
However, some affect tests as follows:
* t/cond36.sh (tparse.h): Fix misspelling of dependency.
* t/disthook.sh: Fix misspelling of file.
* t/help3.sh: Fix misspelling of long option.
* t/instdir-ltlib.sh: Fix misspellings of macro names.
This causes the test to fail, so someone with libtool
expertise needs to look into this.
* t/tap-no-spurious-numbers.sh (highno): Fix misspelling of shell var.
Fixes automake bug https://bugs.gnu.org/10828.
Delete the configure check that would abort if `rm -f` does not work,
and delete the plans to make this a hard requirement in the future.
Instead, test to see if `rm -f` fails w/out arguments. If it does,
define am__rm_f such that it always passes at least the "" argument
when deleting files. If it doesn't fail, then we can omit the "".
Then go through lib/am/ and update places where we use the pattern
`test -z ... || rm -f ...` and replace with $(am__rm_f).
* NEWS: Mention support for `rm -f` w/out arguments.
* PLANS/rm-f-without-args.txt: Remove.
* lib/am/check.am: Use new $(am__rm_f) helper.
* lib/am/clean.am: Likewise.
* lib/am/header-vars.am: Likewise.
* lib/am/inst-vars.am: Likewise.
* lib/am/libs.am: Likewise.
* lib/am/ltlib.am: Likewise.
* lib/am/progs.am: Likewise.
* lib/am/texinfos.am: Likewise.
* m4/init.m4: Delete `rm -f` checks and call _AM_PROG_RM_F.
* m4/rmf.m4: Define new _AM_PROG_RM_F macro.
* t/rm-f-probe.sh: Update test.
In Gnulib, Emacs, etc. we are changing ftp: and http: URLs to use
https:, to discourage man-in-the-middle attacks when downloading
software. The attached patch propagates these changes upstream to
Automake. This patch does not affect files that Automake is
downstream of, which I'll patch separately.
Althouth the resources are not secret, plain HTTP is vulnerable to
malicious routers that tamper with responses from GNU servers,
and this sort of thing is all too common when people in some other
countries browse US-based websites. See, for example:
Aceto G, Botta A, Pescapé A, Awan MF, Ahmad T, Qaisar
S. Analyzing internet censorship in Pakistan. RTSI
2016. https://dx.doi.org/10.1109/RTSI.2016.7740626
HTTPS is not a complete solution here, but it can be a significant
help. The GNU project regularly serves up code to users, so we should
take some care here.
Assume we have package satisfying the following conditions:
(1) automatic dependency tracking is enabled;
(2) the 'subdir-objects' Automake option is enabled;
(3) the package uses a recursive make setup.
Also assume that:
(a) a subdir Makefile declares a foo_SOURCES variable containing
a source file in the parent directory;
(b) that parent Makefile declare a compiled program itself.
Then BSD and Solaris make used to fail when running "make distclean",
because the 'distclean' target of the subdir Makefile removed the
whole '.deps' directory before the parent Makefile was done with the
included '.Po' makefile fragments in that directory. This issue was
revealed by failures in the 'subobj-vpath-pr13928.sh' test when those
make implementations were used.
We fix the issue by ensuring the 'distclean' target of any Makefile
only removed the '.Po' makefile fragments included by it, rather than
the whole '.deps' directory where such files resides.
This change should be the last step in fixing automake bug#13928
for good.
* bin/automake.in (handle_languages), lib/am/depend.am: Adjust
to implement the new 'distclean' logic.
* t/pr224.sh: Adjust to avoid a spurious failure.
* PLANS/subdir-objects.txt: Update.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
* PLANS/obsolete-removed/configure.in.txt: Here. We should refer
to the 'master' branch instead.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
* PLANS/rm-f-without-args.txt: Here. The probe checking that "rm -f"
without arguments works will be introduced in Automake 1.14, not in
Automake 1.13.2.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
This is a follow-up to commit 'v1.13.1b-11-g97aaf12'.
* automake.in: Adjust a comment.
* PLANS: Adjust several files in here.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
See commit v1.13.1-109-g030ecb4 of 2013-01-16, "compat: restore
AM_PROG_MKDIR, again", for the rationale; that rationale is now
also copied...
* PLANS/obsolete-removed/am-prog-mkdir-p.txt: ... here.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
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.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Individual files or sub-directories about future and on-going
development plans in Automake will be added in follow-up commits.
This new set of documents is meant to help ensure a more controlled
and smooth development and evolution for Automake, in several ways.
- Having the plans clearly spelled out should will avoid messy
roadmaps with no clear way forward or with muddy or ill-defined
aims or purposes; a trap this is too easy to fall into.
- Keeping planned changes cooking and re-hashed for a while should
ensure rough edges are smoothed up, transitions are planned in a
proper way (hopefully avoiding debacles like the AM_MKDIR_PROG_P
deprecation and the AM_CONFIG_HEADER too-abrupt removal), and
"power users" have more chances of getting informed in due time,
thus having all the time to prepare for the changes or raise
objections against them.
- Having the plans clearly stated and registered in a "centralized"
location should make it more difficult to them to slip through
the cracks, getting forgotten or (worse) only half-implemented.
- Even for discussions and plans registered on the Bug Tracker
as well, a corresponding entry in the PLANS directory can help
in keeping main ideas summarized, and consensus and/or objections
registered and easily compared.
Motivation:
<http://blog.flameeyes.eu/2013/01/autotools-mythbuster-automake-pains>
Not a flatting picture for us (and maybe a little too harsh), but
basically true and even spot-on in some regards.
* PLANS/README: New.
* Makefile.am (EXTRA_DIST): Distribute the whole PLANS directory.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
