DGJPP: re-introduce support, on Windows 2000 and later
See automake bug#13435.
The problematic DGJPP-related code should no longer be necessary today:
* the code to support DJGPP-style split info files ('*.i[0-9][0-9]')
is no longer needed, since we have dropped support for split info
files anyway (see commit v1.13.1-60-gcdba479 and automake bug#13351);
* on Windows 2000 and later, modern version of DJGPP support file names
starting with dots.
With that, the remaining pieces of code required to support DJGPP on
non-ancient Windows are few and unobtrusive enough that we re-introduce
them, in order to keep DJGPP alive -- the cost/benefit ratio has become
definitely small enough for that.
Note that support for DJGPP on DOS and Windows 95/98/ME is *not*
reintroduced. That is no longer worth worrying about.
For reference, here are the commits where we removed DJGPP support:
- v1.13-6-gad08bbf, "Drop support for DJGPP, MS-DOS, Windows 95/98/ME"
- v1.13-7-gff0c7f8, "general: assume dot-starting file names are supported"
* NEWS: Make clear that DJGPP on Windows 2000 and later should still be
supported.
* automake.in (BEGIN): Override $ENV{SHELL} for DJGPP.
* maintainer/syntax-checks.mk (automake_diff_no): Adjust, as there are
now eight (not just seven) different lines between 'automake.in' and
'automake'.
* bootstrap.sh ($BOOTSTRAP_SHELL): Give a more proper default for DJGPP.
* maint:
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
* 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.
* maint:
tests: more information about Lex and Yacc programs
lint: fix spurious failure for 'sc_rm_minus_f' syntax check
maint: bump version 1.13.1a -> 1.13.2a
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
plans: we are not going to remove AM_PROG_MKDIR_P in Automake 1.14
NEWS: we are not going to remove AM_PROG_MKDIR_P in Automake 1.14
init.m4: add probe to check "rm -f" without args work
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>
OK, this is getting ridiculous, but we cannot remove this macro yet
(and, yes, the fault for this mess lies entirely on me; let's not
dwell on that, thank you very much).
Gettext (so far the greatest "offender" in the use of AM_PROG_MKDIR), in
its latest release 0.18.2, has removed all the uses of that macro still
present in its code base. So I thought we could finally and safely
remove it. Wrong. If a package's 'configure.ac' contains a call like:
AM_GNU_GETTEXT_VERSION([0.18])
then the 'autopoint' script will bring the data files from the Gettext
release *1.18* into the package's tree -- yes, even even if the developer
has installed *and is using* Gettext 1.18.2! Now, these data files
comprise m4 files (that will be seen by subsequent aclocal and autoconf
calls), and of course, the pre-0.18.2 version of some of these files
still contains occurrences of AM_PROG_MKDIR_P -- so Automake 1.13 errors
out, and we lose. This has already happened in practice:
Moreover, while we might see it as not unreasonable to ask a developer
using Automake 1.14 to also update Gettext to 1.18.2, that would not
be enough; in order for gettext to use the correct data files, our
developer would have to update his configure.ac to read:
AM_GNU_GETTEXT_VERSION([0.18.2])
thus requiring *all* of his co-developers to install Gettext 1.18.2,
even if they are still using, say, Automake 1.13. Bad.
So we re-instate this macro as a simple alias for AC_PROG_MKDIR (plus
a non-fatal runtime warning in the 'obsolete' category), and drop any
plan to remove it (see how much good those plans have done us so far).
Note that NEWS is not yet adjusted, since we'll have to adjust it in
maint before (to minimize spurious merge conflicts).
* doc/automake.texi: Update.
* PLANS/obsolete-removed/am-prog-mkdir-p.txt: Likewise.
* t/gettext-macros.sh: Adjust.
* t/am-prog-mkdir-p.sh: New test.
* t/mkdir_p.sh: Remove, folded into the new one.
* t/am-prog-mkdir-p-no-more: Remove as superseded.
* t/list-of-tests.mk: Adjust.
* t/obsolete-err.m4: Re-instate AM_PROG_MKDIR_P as a working
alias for AC_PROG_MKDIR_P (albeit giving runtime warnings, and
calling AC_SUBST on 'mkdir_p' too).
* m4/init.m4 (AM_INIT_AUTOMAKE): No longer call AC_SUBST for
'mkdir_p', as that is once again AM_PROG_MKDIR_P's business.
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.
* maint:
ywrap: remove an obsolete FIXME comment
ywrap: style fixes (no semantic change intended)
convenience: "make lint" as an alias for "make maintainer-check"
docs: typofix in manual
coverage: using multiple lexers in a single program
* maint:
tests: remove most uses of the AM_PROG_CC_C_O obsolete macro
coverage: obsolete macro AM_PROG_CC_C_O should cause no warning nor errors
INSTALL: update copyright years
ithreads: use runtime (not configure time) detection of perl threads
copyright: add few missing copyright notices
maint: files in PLANS are to be exempted from copyright notice
maint: consistently honor the UPDATE_COPYRIGHT_YEAR environment variable
copyright: update some copyright years
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>
maint: consistently honor the UPDATE_COPYRIGHT_YEAR environment variable
* maintainer/maint.mk (update-copyright): Here. The 'lib/update-copyright'
already honoured it, but some parts of our recipe didn't. This has caused
the incomplete copyright bump that was fixed by the previous patch.
* maint:
compile: use 'compile' script when "-c -o" is used with losing compilers
HACKING: suggest more checks before releasing
tests: can fake a compiler not grasping "-c -o" -- globally in all tests
sync: update files from upstream with "make fetch"
typofix: in comments in GNUmakefile
Rename 'maint/' -> 'maintainer/', for Git's sake
HACKING: minor typofix
HACKING: bug-tracker, the PLANS directory, and how to plan "big" changes
HACKING: rewindable branches should live in the 'experimental/*' namespace
HACKING: fixlets about git branch rewinding policy
HACKING: commit messages are not to follow GCS ChangeLog rules too strongly
HACKING: "detailed explanation" in commit messages is almost mandatory
HACKING: we use "merge --log" even when merging master
HACKING: typofix
depend2.am: fix comments on verbosity of compilation rules
depend2.am: improve comments a little
plans: automake 1.14 is to assume "rm -f" with no args is OK
plans: we want to active subdir-objects unconditionally in automake 1.14
compile: use 'compile' script when "-c -o" is used with losing compilers
Do so seen when only source files in the "current" directory are present.
This commit is part of a series of related changes addressing automake
bug#13378 (see also the plan 'PLANS/subdir-objects.txt').
Before this change, Automake-generated C compilation rules mistakenly
passed the "-c -o" options combination unconditionally (even to losing
compiler) when the 'subdir-objects' was used but sources were only
present in the top-level directory. Issue spotted by Nick Bowler:
We fix this by having Automake redefine AC_PROG_CC to take over the role
of AM_PROG_CC_C_O and to require the 'compile' script unconditionally
(albeit that will continue to be invoked only when inferior compilers
are detected).
Among other things, this means AM_PROG_CC_C_O explicitly is no longer
required; that macro is still supported for backward-compatibility, but
calling it is basically a no-op now.
This change has some pros and some cons (obviously, we believe the former
outweighs the latter). Here are the most relevant ones:
+ Pros 1:
Some logic in the Automake script has been simplified.
+ Pros 2:
That simplification has automatically fixed an actual bug (see
Nick's mails referenced above; admittedly, that was present only in
corner-case situations, but still); the test 't/ccnoco4.sh', which
demonstrated the bug and has been failing so far, now passes.
+ Pros 3:
Things works more "automagically" now (no need to manually add the
AM_PROG_CC_C_O macro to configure.ac anymore).
* Cons 1:
The 'compile' script will be required in all projects using C
compilation; this will only be a problem for packages not using
'--add-missing'. However, such packages are definitely more rare
than the ones using '--add-missing', and adjusting them will be
trivial -- just copy the compile script over from the new Automake
installation.
* Cons 2:
The copy & paste of autoconf internals hack this change has introduced
in our "rewrite" of AC_PROG_CC is really an egregious abomination. It
can only be justified with the fact that we expect future versions of
autoconf to implement the semantics we need directly in AC_PROG_CC, so
that we'll be able to leverage that (since Automake 1.14 will require
the latest Autoconf version released).
Now, the detailed list of file-by-file changes ...
* automake.in ($seen_cc_c_o): Remove this global variable.
(scan_autoconf_traces): Don't set it, and do not trace the
'AM_PROG_CC_C_O' m4 macro.
(lang_c_rewrite): Remove, no longer needed.
* doc/automake.texi: Adjust expected "autoreconf --install" output
in the amhello example. Remove statements about the need for the
AM_PROG_CC_C_O macro. Report it is obsolete now.
* m4/init.m4: Re-write AC_PROG_CC to append checks about whether the
C compiler supports "-c -o" together. These checks have basically
been ripped out (with adaptations) from the 'AC_PROG_CC_C_O' macro
of Autoconf and ...
* m4/minuso.m4 (AM_PROG_CC_C_O): ... this macro of ours, which has
thus basically become a no-op.
* t/ax/am-test-lib.sh (am_setup_testdir): Also copy the 'compile'
script in the test directory; if we don't do so, every test using
AC_PROG_CC should call automake with the "--add-missing" option, or
copy the 'compile' script itself.
* t/cond11.sh: No need to create a dummy 'compile' script: that is
already brought in by 'am_setup_testdir()', that is automatically
invoked when 'test-lib.sh' is sourced.
* t/add-missing.tap: Adjust: we expect the 'compile' script to be
required by a mere AC_PROG_CC call now.
* t/dist-auxdir-many-subdirs.sh: Likewise.
* t/specflg6.sh: Likewise.
* t/subobj4.sh: Likewise.
* t/cxx-lt-demo.sh: Likewise, and update comments to match.
* t/distcom2.sh: Enhance a little.
* t/dollarvar2.sh: Adjust.
* t/extra-portability.sh: Likewise.
* t/libobj19.sh: Likewise.
* t/per-target-flags.sh: Likewise.
* t/repeated-options.sh: Likewise.
* t/subobj.sh: Likewise, and enhance a little.
* t/ccnoco2.sh: Remove as obsolete.
* t/list-of-tests.mk (handwritten_TESTS): Adjust.
(XFAIL_TESTS): Remove 't/ccnoco4.sh'.
* NEWS: Update.
tests: can fake a compiler not grasping "-c -o" -- globally in all tests
The ability to easily do so will be quite important in upcoming changes
about C compilation handling and semantics of the 'subdir-objects'
option. Refer to the extensive discussion about automake bug#13378 for
more details: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378>.
See also commit 'v1.13.1-34-g744cd57' of 2013-01-08, "coverage: compile
rules used "-c -o" also with losing compilers".
* t/ax/cc-no-c-o.in: New, a "C compiler" that chokes when the '-c' and
'-o' options are passed together to it on the command line.
* Makefile.am (t/ax/cc-no-c-o): Generate this script from it.
(noinst_SCRIPTS, CLEANFILES): Add it.
(EXTRA_DIST): Add 't/ax/cc-no-c-o.in'.
(check-cc-no-c-o): New target, runs the whole testsuite with 'cc-no-c-o'
as the C compiler (bot GNU and non-GNU).
* .gitignore: Update.
* t/ccnoco.sh: Use the new script instead of duplicating it.
* t/ccnoco3.sh: Likewise.
* t/ccnoco4.sh: Likewise.
* t/self-check-cc-no-c-o.sh: New testsuite self-check.
* t/list-of-tests.mk: Adjust.
Otherwise, Git gets confused by the fact that a directory ('maint')
is named like a branch, and forces me to tweak the command line to
resolve the ambiguity for it.
depend2.am: fix comments on verbosity of compilation rules
The situation and decisions described on those comments have become
quite outdated since the introduction of the silent-rules support.
Today, the general idea is to have nice, terse output if silent rules
are enabled, and complete, faithful, very verbose output if they are
not -- without trying to "massage" this verbose output in a more
pleasant form if that would cause complication in the affected code.
So it's better to just drop the obsolescent comments.
Note that we don't start simplifying the existing rules according
to this new philosophy; that will only be done when touching some
existing code (for the 'depend2.am' code, that will probably happen
on the master branch).
* lib/am/depend2.am: The "fastdep" mode is supported not only for
gcc 3.x, but for gcc 3.x or later, in particular, for all gcc in
the 4.x series (at the time of writing, the latest release is 4.72).
Adjust the comments to match, and re-wrap them while at it.
* maint:
tests: adjust stale references to old test names
tests: rename the last aclocal test with dumb name
tests: fix an old botched change to an aclocal test
tests: fix some botched inter-test references in heading comments
coverage: compile rules used "-c -o" also with losing compilers
texi: remove extra verbosity in creation of dirstamp directory
coverage: user can avoid distributing '.info' pages
plans: add some on-going plans (already registered on the bug tracker)
docs: mention dist-hook help for EXTRA_DIST
texi: remove workaround for older Texinfo (4.1)
NEWS: improve wordings in entry deprecating suffix-less info files
plans: add the "PLANS" directory
* t/remake-renamed-m4-macro-and-file.sh: Adjust to reflect to old
"acloca22 -> t/aclocal-deleted-header.sh" test rename.
* t/aclocal-pr450.sh (configure.ac): Use '$me' in the AC_INIT call,
instead of hard-coding the old name of this test, i.e., "acloca19".
tests: fix an old botched change to an aclocal test
* t/acloca10.sh (configure.ac): Here, invoke the m4 macro 'MACRO2'
before the macro 'MACRO1' (the related test 't/aclocal-I-order-2.sh'
does the opposite). This reverts a botched edit done (by myself,
oops) in commit 'v1.11-1335-gefdc3e1' of 2011-09-11, "tests: minor
optimizations/simplifications in some aclocal tests", and makes the
behaviour of the test match once again what is stated in the
heading comments. While at it, improve those same heading comments
a little.
coverage: compile rules used "-c -o" also with losing compilers
If the 'subdir-objects' option is used, Automake-generated rules for
C compilation pass both the "-c" and "-o" options to the C compiler,
*unconditionally*. There are some compilers that choke on such an
usage, but the AM_PROG_CC_C_O macro takes care of them (it does so by
redefining $CC to use the Automake-provided 'compile' wrapper script
automatically, if a losing compiler is detected at configure runtime).
Unfortunately, in case the 'subdir-objects' option is specified in a
Makefile.am, but all the source files resided anyway in the top-level
directory (relative to the Makefile.am), Automake do *not* complain
if AM_PROG_CC_C_O wasn't invoked in 'configure.ac' -- all the while
still passing "-c -o" to the compiler invocations. This could cause
compilation failures with losing compilers if the user forget to call
AM_PROG_CC_C_O in 'configure.ac' (and Automake would not warn him of
the issue).
Expose this bug in the testsuite.
Issue identified by Nick Bowler in the discussion on automake bug#13378:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
* t/ccnoco4.sh: New test.
* t/list-of-tests.mk (XFAIL_TESTS, handwritten_TESTS): List it.
He also added that "The Elisp manual is one of the largest ones around.
Looks like it would be maybe 3.5mb as one file." Not in any way big by
modern standards.
OTOH, it appears that the use of split info files (at least in the way
they have been handled by Automake-generated rules for a long time) can
cause real problems in some (admittedly quite corner-case) situations:
So we now follow suit with Automake-NG (see commit v1.12.2-901-gdd603e2,
<http://lists.gnu.org/archive/html/automake-ng/2012-08/msg00147.html>)
and have Automake-generated makefiles pass the '--no-split' option
unconditionally to makeinfo invocations.
This allow some nice simplifications in our Texinfo recipes, and offer
an automatic fix for bug#12320.
Another *very* good aspect of such a change is that it should be 100%
transparent to the Automake users.
* lib/am/texinfos.am: Simplify moderately.
* lib/am/texibuild.am: Simplify greatly the recipe for the creation
of info files.
* t/txinfo-makeinfo-error-no-clobber.sh: Adjust.
* t/txinfo-no-split.sh: New test.
* t/list-of-tests.mk: Add it.
coverage: user can avoid distributing '.info' pages
Can be done like this:
AUTOMAKE_OPTIONS = info-in-builddir
dist-info:
@:
Note that this usage is not yet documented: we might decide to go
for a fully-fledged 'no-dist-info' flag, or something like that, in
future automake version (this is not yet decided); in which case,
it's better not to have people start to rely on the hack above.
Still, there's no good reason to break it gratuitously, hence this
test coverage.
* t/txinfo-nodist-info.sh: New test.
* t/list-of-tests.mk: Add it.
* maint:
build: don't enable 'color-tests' automake option explicitly
build: enable all warnings as fatal in our own build system
texi: Texinfo sources and CLEANFILES definition should co-exist peacefully
tests: make two new test executable
runtest: better command line API
tests: move runtest.in away from the top-lever directory
maint: move more maintainer files in the 'maint/' subdir
tests: more significant names for some tests
maint: add some of my maintainer-specific scripts
texi: deprecate hack about info files in CLEANFILES variables
texi: info files can be generated in the builddir
build: enable all warnings as fatal in our own build system
Automake should of course be able to bootstrap itself in a
warning-free manner w.r.t. the Autotools. So make any failure
to do so fatal. Not doing so caused the regression fixed by
previous commit 'v1.13.1-22-ga790fae' to go unnoticed.
* configure.ac (AM_INIT_AUTOMAKE): Add '-Werror' and '-Wall'.
* bootstrap.sh: Pass the '-Wall -Werror' options to aclocal,
automake and autoconf invocations.
texi: Texinfo sources and CLEANFILES definition should co-exist peacefully
But they don't now, due to a regression introduced in commit
'v1.13.1-4-gc1a8f56'. Fix it. The regression was hitting our
own build system!
* automake.in (handle_texinfo_helper): Only complain if the
'info-in-builddir' is not active and a '.info' file (not any
random file!) is listed in CLEANFILES or DISTCLEANFILES.
* t/ax/runtest.in: Accept options '-k' and '--keep-testdirs' (same
as exporting '$keep_testdirs' to "yes"). To improve compatibility
with the "make check" interface, allow environment variables to be
passes on the command line. Minor adjustments while at it.
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.
They are likely not general enough for widespread use, but they
are useful nonetheless.
In the best-case scenario, they will start to be used by other
people, and thus accordingly improved and made more general and
flexible.
In the worst case scenario, well, I still get to keep them in a
centralized, blessed place, simplifying the deployment and use
of them; so still a win for me :-)
* maint:
tests: reorganize tests on backslash issues
style: add trailing ':' to some test cases
tests: tweak tests on obsolete EXTRA_DATA variable
tests: more significant names for some tests
cosmetics: remove few occurrences of trailing whitespace
docs: re-introduce mention of two-args AM_INIT_AUTOMAKE invocation
texi: warn against '.txi' and '.texinfo' input suffixes
cleanup: remove two lines of dead code in automake
texi: warn against suffix-less info files
build: respect silent rules in generation of "amhello" example tarball
projects / thirdparty / automake.git / log
