Navigation:
Browse pkgsrc
(this page) 2013-07-02 08:37:00 by Thomas Klausner | Files touched by this commit (3) |  |
Log message:
Update to 1.14:
* WARNING: New versioning scheme for Automake.
- Beginning with the release 1.13.2, Automake has started to use a
more rational versioning scheme, that should allow users to know
which kind of changes can be expected from a new version, based
on its version number.
+ Micro releases (e.g., 1.13.3, 2.0.1, 3.2.8) introduce only bug
and regression fixes and documentation updates; they should not
introduce new features, nor any backward-incompatibility (any
such incompatibility would be considered a bug, to be fixed with
a further micro release).
+ Minor releases (e.g., 1.14, 2.1) can introduce new backward
compatible features; the only backward-incompatibilities allowed
in such a release are new *non-fatal* deprecations and warnings,
and possibly fixes for old or non-trivial bugs (or even inefficient
behaviours) that could unfortunately have been seen and used by
some as "corner case features". Possible disruptions caused by
this kind of fixes should hopefully be quite rare, and their
effects limited in scope.
+ Major versions (now expected to be released every 18 or 24 months,
and not more often) can introduce new big features (possibly with
rough edges and not-fully-stabilized APIs), removal of deprecated
features, backward-incompatible changes of behaviour, and possibly
major refactorings (that, while ideally transparent to the user,
could introduce new bugs). Incompatibilities should however not
be introduced gratuitously and abruptly; a proper deprecation path
should be duly implemented in the preceding minor releases.
- According to this new scheme, the next major version of Automake
(the one that had previously been labelled as "1.14") will actually
become "Automake 2.0". Automake 1.14 is *this* release (which is
a minor one). It introduces new features, deprecations and bug
fixes, but no serious backward incompatibility. A partial exception
is given by the behavioural changes in the AM_PROG_CC_C_O macro
(described in details below) but such changes can also be seen as a
fix for the old suboptimal and somewhat confusing behaviour.
- See discussion about automake bug#13578 for more details and
background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* WARNING: Future backward-incompatibilities!
- Makefile recipes generated by Automake 2.0 will expect to use an
'rm' program that doesn't complain when called without any non-option
argument if the '-f' option is given (so that commands like "rm -f"
and "rm -rf" will act as a no-op, instead of raising usage errors).
This behavior of 'rm' is very widespread in the wild, and it will be
required in the next POSIX version:
<http://austingroupbugs.net/view.php?id=542>
Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
that the default 'rm' program in PATH satisfies this requirement,
aborting the configure process if this is not the case. For the
moment, it's still possible to force the configuration process to
succeed even with a broken 'rm', that that will no longer be the case
for Automake 2.0.
- Automake 2.0 will require Autoconf 2.70 or later (which is still
unreleased at the moment of writing, but is planned to be released
before Automake 2.0 is).
- Automake 2.0 will drop support for the long-deprecated 'configure.in'
name for the Autoconf input file. You are advised to start using the
recommended name 'configure.ac' instead, ASAP.
- The ACLOCAL_AMFLAGS special make variable will be fully deprecated in
Automake 2.0: it will raise warnings in the "obsolete" category (but
still no hard error of course, for compatibilities with the many, many
packages that still relies on that variable). You are advised to
start relying on the new Automake support for AC_CONFIG_MACRO_DIRS
instead (which was introduced in Automake 1.13).
- Automake 2.0 will remove support for automatic dependency tracking
with the SGI C/C++ compilers on IRIX. The SGI depmode has been
reported broken "in the wild" already, and we don't think investing
time in debugging and fixing is worthwhile, especially considering
that SGI has last updated those compilers in 2006, and is expected
to retire support for them in December 2013:
<http://www.sgi.com/services/support/irix_mips_support.html>
- Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME
(support for them was offered by relying on the DJGPP project).
Note however that both Cygwin and MSYS/MinGW on modern Windows
versions will continue to be fully supported.
- Automake-provided scripts and makefile recipes might (finally!)
start assuming a POSIX shell in Automake 2.0. There still is no
certainty about this though: we'd first like to wait and see
whether future Autoconf versions will be enhanced to guarantee
that such a shell is always found and provided by the checks in
./configure.
- Starting from Automake 2.0, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will take precedence
over "built-in" Automake macros. For example (assuming Automake
is installed in the /usr/local hierarchy), a definition of the
AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
(defined in '/usr/local/share/aclocal-2.0/vala.m4').
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.14:
* C compilation, and the AC_PROG_CC and AM_PROG_CC_C_O macros:
- The 'compile' script is now unconditionally required for all packages
that perform C compilation (if you are using the '--add-missing'
option, automake will fetch that script for you, so you shouldn't
need any explicit adjustment). This new behaviour is needed to avoid
obscure errors when the 'subdir-objects' option is used, and the
compiler is an inferior one that doesn't grasp the combined use of
both the "-c -o" options; see discussion about automake bug#13378 for
more details:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
- The next major Automake version (2.0) will unconditionally activate
the 'subdir-objects' option. In order to smooth out the transition,
we now give a warning (in the category 'unsupported') whenever a
source file is present in a subdirectory but the 'subdir-object' is
not enabled. For example, the following usage will trigger such a
warning:
bin_PROGRAMS = sub/foo
sub_foo_SOURCES = sub/main.c sub/bar.c
- Automake will automatically enhance the autoconf-provided macro
AC_PROG_CC to force it to check, at configure time, that the
C compiler supports the combined use of both the '-c' and '-o'
options. The result of this check is saved in the cache variable
'am_cv_prog_cc_c_o', and said result can be overridden by
pre-defining that variable.
- The AM_PROG_CC_C_O macro can still be called, albeit that should no
longer be necessary. This macro is now just a thin wrapper around the
Automake-enhanced AC_PROG_CC. This means, among the other things,
that its behaviour is changed in three ways:
1. It no longer invokes the Autoconf-provided AC_PROG_CC_C_O
macro behind the scenes.
2. It caches the check result in the 'am_cv_prog_cc_c_o' variable,
and not in a 'ac_cv_prog_cc_*_c_o' variable whose exact name is
dynamically computed only at configure runtime (really!) from
the content of the '$CC' variable.
3. It no longer automatically AC_DEFINE the C preprocessor
symbol 'NO_MINUS_C_MINUS_O'.
* Texinfo support:
- Automake can now be instructed to place '.info' files generated from
Texinfo input in the builddir rather than in the srcdir; this is done
specifying the new automake option 'info-in-builddir'. This feature
was requested by the developers of GCC, GDB, GNU binutils and the GNU
bfd library. See the extensive discussion about automake bug#11034
for more details.
- For quite a long time, Automake has been implementing an undocumented
hack which ensured that '.info' files which appeared to be cleaned
(by being listed in the CLEANFILES or DISTCLEANFILES variables) were
built in the builddir rather than in the srcdir; this hack was
introduced to ensure better backward-compatibility with package
such as Texinfo, which do things like:
info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
DISTCLEANFILES = texinfo texinfo-* info*.info*
# Do not create info files for distribution.
dist-info:
@:
in order not to distribute generated '.info' files.
Now that we have the 'info-in-builddir' option that explicitly causes
generated '.info' files to be placed in the builddir, this hack should
be longer necessary, so we deprecate it with runtime warnings. It will
likely be removed altogether in Automake 2.0.
* Relative directory in Makefile fragments:
- The special Automake-time substitutions '%reldir%' and '%canon_reldir%'
(and their short versions, '%D%' and '%C%' respectively) can now be used
in an included Makefile fragment. The former is substituted with the
relative directory of the included fragment (compared to the top-level
including Makefile), and the latter with the canonicalized version of
the same relative directory.
# in 'Makefile.am':
bin_PROGRAMS = # will be updated by included Makefile fragments
include src/Makefile.inc
# in 'src/Makefile.inc':
bin_PROGRAMS += %reldir%/foo
%canon_reldir%_foo_SOURCES = %reldir%/bar.c
This should be especially useful for packages using a non-recursive
build system.
* Deprecated distribution formats:
- The 'shar' and 'compress' distribution formats are deprecated, and
scheduled for removal in Automake 2.0. Accordingly, the use of the
'dist-shar' and 'dist-tarZ' will cause warnings at automake runtime
(in the 'obsolete' category), and the recipes of the Automake-generated
targets 'dist-shar' and 'dist-tarZ' will unconditionally display
(non-fatal) warnings at make runtime.
* New configure runtime warnings about "rm -f" support:
- To simplify transition to Automake 2.0, the shell code expanded by
AM_INIT_AUTOMAKE now checks (at configure runtime) that the default
'rm' program in PATH doesn't complain when called without any
non-option argument if the '-f' option is given (so that commands like
"rm -f" and "rm -rf" act as a no-op, instead of raising \
usage errors).
If this is not the case, the configure script is aborted, to call the
attention of the user on the issue, and invite him to fix his PATH.
The checked 'rm' behavior is very widespread in the wild, and will be
required by future POSIX versions:
<http://austingroupbugs.net/view.php?id=542>
The user can still force the configure process to complete even in the
presence of a broken 'rm' by defining the ACCEPT_INFERIOR_RM_PROGRAM
environment variable to "yes". And the generated Makefiles should
still work correctly even when such broken 'rm' is used. But note
that this will no longer be the case with Automake 2.0 though, so, if
you encounter the warning, please report it to us ASAP (and try to fix
your environment as well).
|
| 2013-06-08 12:54:04 by Thomas Klausner | Files touched by this commit (2) |
Log message:
Update to 1.13.3:
New in 1.13.3:
* Documentation fixes:
- The documentation no longer mistakenly reports that the obsolete
'AM_MKDIR_PROG_P' macro and '$(mkdir_p)' make variable are going
to be removed in Automake 2.0.
* Bugs fixed:
- Byte-compilation of Emacs lisp files could fail spuriously on
Solaris, when /bin/ksh or /usr/xpg4/bin/sh were used as shell.
- If the same user-defined suffixes were transformed into different
Automake-known suffixes in different Makefile.am files in the same
project, automake could get confused and generate inconsistent
Makefiles (automake bug#14441).
For example, if 'Makefile.am' contained a ".ext.cc:" suffix rule,
and 'sub/Makefile.am' contained a ".ext.c:" suffix rule, automake
would have mistakenly placed into 'Makefile.in' rules to compile
"*.c" files into object files, and into 'sub/Makefile.in' rules to
compile "*.cc" files into object files --- rather than the other
way around. This is now fixed.
* Testsuite work:
- The test cases no longer have the executable bit set. This should
make it clear that they are not meant to be run directly; as
explained in t/README, they can only be run through the custom
'runtest' script, or by a "make check" invocation.
- The testsuite has seen the introduction of a new helper function
'run_make', and several related changes. These serve a two-fold
purpose:
1. Remove brittleness due to the use of "make -e" in test cases.
2. Seamlessly allow the use of parallel make ("make -j...") in the
test cases, even where redirection of make output is involved
(see automake bug#11413 for a description of the subtle issues
in this area).
- Several spurious failures have been fixed (they hit especially
MinGW/MSYS builds). See automake bugs #14493, #14494, #14495,
#14498, #14499, #14500, #14501, #14517 and #14528.
- Some other minor miscellaneous changes and fixlets.
|
| 2013-05-31 14:42:58 by Thomas Klausner | Files touched by this commit (2880) |
Log message: Bump all packages for perl-5.18, that a) refer 'perl' in their Makefile, or b) have a directory name of p5-*, or c) have any dependency on any p5-* package Like last time, where this caused no complaints. |
| 2013-05-18 16:48:24 by Thomas Klausner | Files touched by this commit (3) | |
Log message:
Update to 1.13.2:
* WARNING: New versioning scheme for Automake.
- Starting with this version onward, Automake will use an update and
more rational versioning scheme, one that will allow users to know
which kind of changes can be expected from a new version, based on
its version number.
+ Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only
documentation updates and bug and regression fixes; they will
not introduce new features, nor any backward-incompatibility (any
such incompatibility would be considered a bug, to be fixed with
a further micro release).
+ Minor versions (e.g., 1.14, 2.1) can introduce new backward
compatible features; the only backward-incompatibilities allowed
in such a release are new *non-fatal* deprecations and warnings,
and possibly fixes for old or non-trivial bugs (or even inefficient
behaviours) that could unfortunately have been seen, and used, by
some developers as "corner case features". Possible disruptions
caused by this kind of fixes should hopefully be quite rare.
+ Major versions (now expected to be released every 18 or 24 months,
and not more often) can introduce new big features (possibly with
rough edges and not-fully-stabilized APIs), removal of deprecated
features, backward-incompatible changes of behaviour, and possibly
major refactorings (that, while ideally transparent to the user,
could introduce new bugs). Incompatibilities should however not
be introduced gratuitously and abruptly; a proper deprecation path
should be duly implemented in the preceding minor releases.
- According to this new scheme, the next major version of Automake
(the one that has until now been labelled as '1.14') will actually
become "Automake 2.0". Automake 1.14 will be the next minor version,
which will introduce new features, deprecations and bug fixes, but
no real backward incompatibility.
- See discussion about automake bug#13578 for more details and
background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
* WARNING: Future backward-incompatibilities!
- Automake 2.0 will require Autoconf 2.70 or later (which is still
unreleased at the moment of writing, but is planned to be released
before Automake 2.0 is).
- Automake 2.0 will drop support for the long-deprecated 'configure.in'
name for the Autoconf input file. You are advised to start using the
recommended name 'configure.ac' instead, ASAP.
- The ACLOCAL_AMFLAGS special make variable will be fully deprecated
in Automake 2.0 (where it will raise warnings in the "obsolete"
category). You are advised to start relying on the new Automake
support for AC_CONFIG_MACRO_DIRS instead (which was introduced in
Automake 1.13).
- Automake 2.0 will remove support for automatic dependency tracking
with the SGI C/C++ compilers on IRIX. The SGI depmode has been
reported broken "in the wild" already, and we don't think investing
time in debugging and fixing is worthwhile, especially considering
that SGI has last updated those compilers in 2006, and is expected
to retire support for them in December 2013:
<http://www.sgi.com/services/support/irix_mips_support.html>
- Future versions of Automake might remove support for MS-DOS and
Windows 95/98/ME (support for them was offered by relying on the
DJGPP project). Note however that both Cygwin and MSYS/MinGW on
modern Windows versions will continue to be fully supported.
- Automake-provided scripts and makefile recipes might (finally!)
start assuming a POSIX shell in Automake 2.0.
- Starting from Automake 2.0, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will take precedence
over "built-in" Automake macros. For example (assuming Automake
is installed in the /usr/local hierarchy), a definition of the
AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
(defined in '/usr/local/share/aclocal-2.0/vala.m4').
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.2:
* Obsolescent features:
- Use of suffix-less info files (that can be specified through the
'@setfilename' macro in Texinfo input files) is discouraged, and
its use will raise warnings in the 'obsolete' category.
- Use of Texinfo input files with '.txi' or '.texinfo' extensions
is discouraged, and its use will raise warnings in the 'obsolete'
category. You are advised to simply use the '.texi' extension
instead.
* Documentation fixes:
- The long-deprecated but still supported two-arguments invocation form
of AM_INIT_AUTOMAKE is documented once again. This seems the sanest
thing to do, given that support for such an usage might need to remain
in place for a unspecified amount of time in order to cater for people
who want to define the version number for their package dynamically at
configure runtime (unfortunately, Autoconf does not yet support this
scenario, so we cannot delegate the work to it).
- The serial testsuite harness is no longer reported as "deprecated",
but as "discouraged". We have no plan to remove it, not to make its
use cause runtime warnings.
- The parallel testsuite is no longer reported as "experimental"; it
is well tested, and should be stable now.
- The 'shar' and 'tarZ' distribution formats and the 'dist-shar' and
'dist-tarZ' options are obsolescent, and their use is deprecated
in the documentation.
- Other minor miscellaneous fixes and improvements; in particular,
some improvements in cross-references.
* Bugs fixed:
- When the 'ustar' option is used, the generated configure script no
longer risks hanging during the tests for the availability of the
'pax' utility, even if the user running configure has a UID or GID
that requires more than 21 bits to be represented.
See automake bug#8343 and bug#13588.
- The obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC work once
again, as they did in Automake 1.12.x (albeit printing runtime
warnings in the 'obsolete' category). Removing them has turned
out to be a very bad idea, because it complicated distro packing
enormously. Making them issue fatal warnings, as we did in
Automake 1.13, has turned out to be a similarly very bad idea,
for exactly the same reason.
- aclocal will no longer error out if the first local m4 directory
(as specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or
'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it will merely report
a warning in the 'unsupported' category. This is done to support
some pre-existing real-world usages. See automake bug#13514.
- aclocal will no longer consider directories for extra m4 files more
than once, even if they are specified multiple times. This ensures
packages that specify both
AC_CONFIG_MACRO_DIR([m4]) in configure.ac
ACLOCAL_AMFLAGS = -I m4 in Makefile.am
will work correctly, even when the 'm4' directory contains no
package-specific files, but is used only to install third-party
m4 files (as can happen with e.g., "libtoolize --install").
See automake bug#13514.
- Analysis of make flags in Automake-generated rules has been made more
robust, and more future-proof. For example, in presence of make that
(like '-I') take an argument, the characters in said argument will no
longer be spuriously considered as a set of additional make options.
In particular, automake-generated rules will no longer spuriously
believe to be running in dry mode ("make -n") if run with an invocation
like "make -I noob"; nor will they believe to be running in keep-going
mode ("make -k") if run with an invocation like "make -I \
kool"
(automake bug#12554).
|
| 2013-01-21 14:51:23 by Thomas Klausner | Files touched by this commit (3) | |
Log message:
Update to 1.13.1. Let me know what breaks (in pkgsrc only :) ).
New in 1.13.1:
* WARNING: Future backward-incompatibilities!
- Automake 1.14 will likely require Autoconf 2.70 or later (which is
still unreleased at the moment of writing, but is planned to be
released before Automake 1.14 is).
- Automake 1.14 will likely drop support for the long-deprecated
'configure.in' name for the Autoconf input file. You are advised
to use the recommended name 'configure.ac' instead.
- The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
be removed in Automake 1.14. The $(mkdir_p) make variable and the
@mkdir_p@ substitution will still remain available (as aliases of
$(MKDIR_P)) for the moment, for better backward compatibility; but
you are advised to stop using ASAP.
- The ACLOCAL_AMFLAGS special make variable will be fully deprecated
in Automake 1.14 (where it will raise warnings in the "obsolete"
category). You are advised to start relying on the new Automake
support for AC_CONFIG_MACRO_DIRS instead (which is introduced with
this release; see below for more information).
- Support for IRIX and the SGI C/C++ compilers will be removed in
Automake 1.14: they have seen their last release in 2006, and SGI
is expected to retire support from them in December 2013; see
<http://www.sgi.com/services/support/irix_mips_support.html> for
more information.
- Future versions of Automake might remove support for MS-DOS and
Windows 95/98/ME (support for them was offered by relying on the
DJGPP project). Note however that both Cygwin and MSYS/MinGW on
modern Windows versions will continue to be fully supported.
- Support for the long-deprecated INCLUDES variable will be removed
altogether in Automake 1.14. The AM_CPPFLAGS variable should be
used instead.
- Automake-provided scripts and makefile recipes might (finally!)
start assuming a POSIX shell in Automake 1.14.
- Starting from Automake 1.14, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will take precedence
over "built-in" Automake macros. For example (assuming Automake
is installed in the /usr/local hierarchy), a definition of the
AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
(defined in '/usr/local/share/aclocal-1.14/vala.m4').
* Bugs fixed:
- Use of the obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC now
causes a clear and helpful error message, instead of obscure ones
(issue introduced in Automake 1.13).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13:
* Bugs fixed:
- ylwrap renames properly header guards in generated header files
(*.h), instead of leaving Y_TAB_H.
- ylwrap now also converts header guards in implementation files
(*.c). Because ylwrap failed to rename properly #include in the
implementation files, current versions of Bison (e.g., 2.7)
duplicate the generated header file in the implementation file.
The header guard then protects the implementation file from
duplicate definitions from the header file.
* Version requirements:
- Autoconf 2.65 or greater is now required.
- The rules to build PDF and DVI output from Texinfo input now
require Texinfo 4.9 or later.
* Obsolete features:
- Support for the "Cygnus-style" trees (once enabled by the 'cygnus'
option) has been removed. See discussion about automake bug#11034
for more background: <http://debbugs.gnu.org/11034>.
- The deprecated aclocal option '--acdir' has been removed. You
should use the options '--automake-acdir' and '--system-acdir'
instead (which have been introduced in Automake 1.11.2).
- The following long-obsolete m4 macros have been removed:
AM_PROG_CC_STDC: superseded by AC_PROG_CC since October 2002
fp_PROG_CC_STDC: broken alias for AM_PROG_CC_STDC
fp_WITH_DMALLOC: old alias for AM_WITH_DMALLOC
AM_CONFIG_HEADER: superseded by AC_CONFIG_HEADERS since July 2002
ud_PATH_LISPDIR: old alias for AM_PATH_LISPDIR
jm_MAINTAINER_MODE: old alias for AM_MAINTAINER_MODE
ud_GNU_GETTEXT: old alias for AM_GNU_GETTEXT
gm_PROG_LIBTOOL: old alias for AC_PROG_LIBTOOL
fp_C_PROTOTYPES: old alias for AM_C_PROTOTYPES (which was part
of the now-removed automatic de-ANSI-fication
support of Automake)
- All the "old alias" macros in 'm4/obsolete.m4' have been removed.
- Use of the long-deprecated two- and three-arguments invocation forms
of the AM_INIT_AUTOMAKE is no longer documented. It's still supported
though (albeit with a warning in the 'obsolete' category), to cater
for people who want to define the version number for their package
dynamically (e.g., from the current VCS revision). We'll have to
continue this support until Autoconf itself is fixed to allow better
support for such dynamic version numbers.
* Elisp byte-compilation:
- The byte compilation of '.el' files into '.elc' files is now done
with a suffix rule. This has simplified the compilation process, and
more importantly made it less brittle. The downside is that emacs is
now invoked once for each '.el' files, which cause some noticeable
slowdowns. These should however be mitigated on multicore machines
(which are becoming the norm today) if concurrent make ("make -j")
is used.
- Elisp files placed in a subdirectory are now byte-compiled to '.elc'
files in the same subdirectory; for example, byte-compiling of file
'sub/foo.el' file will result in 'sub/foo.elc' rather than in
'foo.elc'. This behaviour is backward-incompatible with older
Automake versions, but it is more natural and more sane. See also
automake bug#7441.
- The Emacs invocation performing byte-compilation of '.el' files honors
the $(AM_ELCFLAGS) and $(ELCFLAGS) variables; as typical, the former
one is developer-reserved and the latter one user-reserved.
- The 'elisp-comp' script, once provided by Automake, has been rendered
obsoleted by the just-described changes, and thus removed.
* Changes to Automake-generated testsuite harnesses:
- The parallel testsuite harness (previously only enabled by the
'parallel-tests' option) is the default one; the older serial
testsuite harness will still be available through the use of the
'serial-tests' option (introduced in Automake 1.12).
- The 'color-tests' option is now unconditionally activated by default.
In particular, this means that testsuite output is now colorized by
default if the attached terminal seems to support ANSI escapes, and
that the user can force output colorization by setting the variable
AM_COLOR_TESTS to "always". The 'color-tests' is still recognized
for backward-compatibility, although it's a handled as a no-op now.
* Silent rules support:
- Support for silent rules is now always active in Automake-generated
Makefiles. So, although the verbose output is still the default,
the user can now always use "./configure --enable-silent-rules" or
"make V=0" to enable quieter output in the package he's building.
- The 'silent-rules' option has now become a no-op, preserved for
backward-compatibility only. In particular, its use no longer
disables the warnings in the 'portability-recursive' category.
* Texinfo Support:
- The rules to build PDF and DVI files from Texinfo input now require
Texinfo 4.9 or later.
- The rules to build PDF and DVI files from Texinfo input now use the
'--build-dir' option, to keep the auxiliary files used by texi2dvi
and texi2pdf around without cluttering the build directory, and to
make it possible to run the "dvi" and "pdf" recipes in \
parallel.
* Automatic remake rules and 'missing' script:
- The 'missing' script no longer tries to update the timestamp of
out-of-date files that require a maintainer-specific tool to be
remade, in case the user lacks such a tool (or has a too-old version
of it). It just gives a useful warning, and in some cases also a
tip about how to obtain such a tool.
- The missing script has thus become useless as a (poor) way to work
around the sketched-timestamps issues that can happen for projects
that keep generated files committed in their VCS repository. Such
projects are now encouraged to write a custom "fix-timestamps.sh"
script to avoid such issues; a simple example is provided in the
"CVS and generated files" chapter of the automake manual.
* Recursive targets:
- The user can now define his own recursive targets that recurse
in the directories specified in $(SUBDIRS). This can be done by
specifying the name of such targets in invocations of the new
'AM_EXTRA_RECURSIVE_TARGETS' m4 macro.
* Tags:
- Any failure in the recipe of the "tags", "ctags", \
"cscope" or
"cscopelist" targets in a subdirectory is now propagated to the
top-level make invocation.
- Tags are correctly computed also for files in _SOURCES variables that
only list files with non-standard suffixes (see automake bug#12372).
* Improvements to aclocal and related rebuilds rules:
- Autoconf-provided macros AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS
are now traced by aclocal, and can be used to declare the local m4
include directories. Formerly, one had to specify it with an explicit
'-I' option to the 'aclocal' invocation.
- The special make variable ACLOCAL_AMFLAGS is deprecated; future
Automake versions will warn about its use, and later version will
remove support for it altogether.
* The depcomp script:
- Dropped support for libtool 1.4.
- Various internal refactorings. They should cause no visible change,
but the chance for regression is there anyway, so please report any
unexpected or suspicious behaviour.
- Support for pre-8.0 versions of the Intel C Compiler has been dropped.
This should cause no problem, since icc 8.0 has been released in
December 2003 -- almost nine years ago.
- Support for tcc (the Tiny C Compiler) has been improved, and is now
handled through a dedicated 'tcc' mode.
* The ylwrap script:
- ylwrap generates header guards with a single '_' for series of non
alphabetic characters, instead of several. This is what Bison >=
2.5.1 does.
|
| 2012-12-16 11:41:11 by Thomas Klausner | Files touched by this commit (2) |
Log message:
Update to 1.12.6:
(same backwards compat warnings related to 1.13 as in 1.12.5)
Bugs fixed in 1.12.6:
* Python-related bugs:
- The default installation location for python modules has been improved
for Python 3 on Debian and Ubuntu systems, changing from:
${prefix}/lib/python3/dist-packages
to
${prefix}/lib/python3.x/site-packages
This change should ensure modules installed using the default ${prefix}
"/usr/local" are found by default by system python 3.x installations.
See automake bug#10227.
- Python byte-compilation supports the new layout mandated by PEP-3147,
with its __pycache__ directory (automake bug#8847).
* Build system issues:
- The maintainer rebuild rules for Makefiles and aclocal.m4 in
Automake's own build system works correctly again (bug introduced
in Automake 1.12.5).
* Testsuite issues:
- The Vala-related tests has been changed to adjust to the removal of
the 'posix' profile in the valac compiler. See automake bug#12934
a.k.a. bug#12522.
- Some spurious testsuite failures related to older tools and systems
have been fixed.
|
| 2012-12-09 16:06:48 by Thomas Klausner | Files touched by this commit (2) | |
Log message:
Update to 1.12.5:
New in 1.12.5:
* WARNING: Future backward-incompatibilities!
- Future versions of Automake will likely drop support for the
long-deprecated 'configure.in' name for the Autoconf input file.
You are advised to use the recommended name 'configure.ac' instead.
- Support for the "Cygnus-style" trees (as enabled by the 'cygnus'
option) will be removed in the next major Automake release (1.13).
- The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
be removed in Automake 1.13. The $(mkdir_p) make variable and the
@mkdir_p@ substitution will still remain available (as aliases of
$(MKDIR_P)) for the moment, for better backward compatibility.
- Autoconf 2.65 or later will be required by the next major Automake
version (1.13). Until now, Automake has required Autoconf version
2.62 or later.
- Starting from the next major Automake version (1.13), the rules
to build pdf, ps and dvi output from Texinfo input will use the
'--build-dir' option by default. Since such an option was only
introduced in Texinfo 4.9, this means that Makefiles generated by
future Automake versions will require at least that version of
Texinfo.
- Starting from the next major Automake version (1.13), the parallel
testsuite harness (previously only enabled by the 'parallel-tests'
option) will become the default one; the older serial testsuite
harness will still be available through the use of the 'serial-tests'
option.
- The following long-obsolete m4 macros will be removed in the
next major Automake version (1.13):
AM_PROG_CC_STDC: superseded by AC_PROG_CC since October 2002
fp_PROG_CC_STDC: broken alias for AM_PROG_CC_STDC
fp_WITH_DMALLOC: old alias for AM_WITH_DMALLOC
AM_CONFIG_HEADER: superseded by AC_CONFIG_HEADERS since July 2002
ud_PATH_LISPDIR: old alias for AM_PATH_LISPDIR
jm_MAINTAINER_MODE: old alias for AM_MAINTAINER_MODE
ud_GNU_GETTEXT: old alias for AM_GNU_GETTEXT
gm_PROG_LIBTOOL: old alias for AC_PROG_LIBTOOL
fp_C_PROTOTYPES: old alias for AM_C_PROTOTYPES (which was part
of the now-removed automatic de-ANSI-fication
support of Automake)
- All the "old alias" macros in 'm4/obsolete.m4' will be removed in
the next major Automake version (1.13).
- The '--acdir' option of aclocal is deprecated, and will probably
be removed in the next major Automake release (1.13). You should
use the options '--automake-acdir' and '--system-acdir' instead
(which have been introduced in Automake 1.11.2).
- The 'missing' script will no longer try to update the timestamp
of out-of-date files that require a maintainer-specific tool to be
remade, in case the user lacks such a tool (or has a too-old version
of it). In fact, starting from Automake 1.13, all it'll do will be
giving more useful warnings than a bare "command not found" from a
make recipe would.
* Vala support:
- The AM_PROG_VALAC macro has been enhanced to takes two further
optional arguments; it's signature now being
AM_PROG_VALAC([MINIMUM-VERSION], [ACTION-IF-FOUND],
[ACTION-IF-NOT-FOUND])
- By default, AM_PROG_VALAC no longer aborts the configure invocation
if the Vala compiler found is too old, but simply prints a warning
messages (as it did when the Vala compiler was not found). This
should avoid unnecessary difficulties for end users that just want
to compile the unmodified, distributed Vala-generated C sources,
but happens to have an old Vala compiler in their PATH. This fixes
automake bug#12688.
- If no proper Vala compiler is found at configure runtime, AM_PROG_VALAC
will set the AC_SUBST'd variable 'VALAC' to 'valac' rather than to ':'.
This is a better default, because with it a triggered makefile rule
invoking a Vala compilation will clearly fail with an informative error
message like "valac: command not found", rather than silently, with
the error possibly going unnoticed or triggering harder-to-diagnose
fallout failures in later steps.
* Miscellaneous changes:
- automake and aclocal no longer honours the 'perllibdir' environment
variable. That had always been intended only as an hack required in
the testsuite, not meant for any use beyond that.
Bugs fixed in 1.12.5:
* Long-standing bugs:
- Automake no longer generates spurious remake rules invoking autoheader
to regenerate the template corresponding to header files specified after
the first one in AC_CONFIG_HEADERS (automake bug#12495).
- When wrapping Microsoft tools, the 'compile' script falls back to
finding classic 'libname.a' style libraries when 'name.lib' and
'name.dll.lib' aren't available.
|
| 2012-10-31 12:19:55 by Aleksej Saushev | Files touched by this commit (1460) |
Log message: Drop superfluous PKG_DESTDIR_SUPPORT, "user-destdir" is default these days. |
| 2012-10-03 23:59:10 by Thomas Klausner | Files touched by this commit (2798) |
Log message: Bump all packages that use perl, or depend on a p5-* package, or are called p5-*. I hope that's all of them. |
| 2012-10-02 19:15:11 by Thomas Klausner | Files touched by this commit (2) | |
Log message:
Update to 1.12.4:
New in 1.12.4:
* WARNING: Future backward-incompatibilities!
- Future versions of Automake will likely drop support for the
long-deprecated 'configure.in' name for the Autoconf input file.
You are advised to use the recommended name 'configure.ac' instead.
- Support for the "Cygnus-style" trees (as enabled by the 'cygnus'
option) will be removed in the next major Automake release (1.13).
- The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
be removed in Automake 1.13. The $(mkdir_p) make variable and the
@mkdir_p@ substitution will still remain available (as aliases of
$(MKDIR_P)) for the moment, for better backward compatibility.
- Autoconf 2.65 or later will be required by the next major Automake
version (1.13). Until now, Automake has required Autoconf version
2.62 or later.
- Starting from the next major Automake version (1.13), the rules
to build pdf, ps and dvi output from Texinfo input will use the
'--build-dir' option by default. Since such an option was only
introduced in Texinfo 4.9, this means that Makefiles generated by
future Automake versions will require at least that version of
Texinfo.
- Starting from the next major Automake version (1.13), the parallel
testsuite harness (previously only enabled by the 'parallel-tests'
option) will become the default one; the older serial testsuite
harness will still be available through the use of the 'serial-tests'
option.
- The following long-obsolete m4 macros will be removed in the
next major Automake version (1.13):
AM_PROG_CC_STDC: superseded by AC_PROG_CC since October 2002
fp_PROG_CC_STDC: broken alias for AM_PROG_CC_STDC
fp_WITH_DMALLOC: old alias for AM_WITH_DMALLOC
AM_CONFIG_HEADER: superseded by AC_CONFIG_HEADERS since July 2002
ud_PATH_LISPDIR: old alias for AM_PATH_LISPDIR
jm_MAINTAINER_MODE: old alias for AM_MAINTAINER_MODE
ud_GNU_GETTEXT: old alias for AM_GNU_GETTEXT
gm_PROG_LIBTOOL: old alias for AC_PROG_LIBTOOL
fp_C_PROTOTYPES: old alias for AM_C_PROTOTYPES (which was part
of the now-removed automatic de-ANSI-fication
support of Automake)
- All the "old alias" macros in 'm4/obsolete.m4' will be removed in
the next major Automake version (1.13).
- The '--acdir' option of aclocal is deprecated, and will probably
be removed in the next major Automake release (1.13). You should
use the options '--automake-acdir' and '--system-acdir' instead
(which have been introduced in Automake 1.11.2).
- The 'missing' script will not try anymore to update the timestamp
of out-of-date files that require a maintainer-specific tool to be
remade, in case the user lacks such a tool (or has a too-old version
of it). In fact, starting from Automake 1.13, all it'll do will be
giving more useful warnings than a bare "command not found" from a
make recipe would.
* Warnings and deprecations:
- Warnings in the 'obsolete' category are enabled by default both in
automake and aclocal.
* Miscellaneous changes:
- Some testsuite weaknesses and spurious failures have been fixed.
|
New packages: