-
Show log
Commit
-
Hash : bd34a47c
Author :
Date : 2012-01-21T11:33:44
multilib: move to contrib This follows up on commit v1.11-665-gc5df21e of 2012-01-17, "multilib: deprecate, will be moved to contrib". See also: <http://lists.gnu.org/archive/html/automake-patches/2012-01/msg00109.html> * NEWS: Update. * automake.in ($seen_multilib): Remove. (scan_autoconf_traces): Don't trace 'AM_ENABLE_MULTILIB', and don't handle it anymore. (handle_multilib): Remove. (generate_makefile): Don't call it anymore. * doc/automake.texi: Remove documentation about multilib support, related macros, and helper files. * m4/multi.m4: Delete. * m4/Makefile.am (dist_automake_ac_DATA): Remove it. * lib/am/multilib.am: Delete. * lib/am/Makefile.am (dist_am_DATA): Remove it. * contrib/multilib/multilib.am: New file, adapted from extracts of a Makefile.in generated with automake multilib support. We did this instead of moving and editing 'lib/am/multilib.am' because it allows us to license this file with a liberal license that will permit users to copy-and-paste it in non-GPLed Makefile.am files too). * lib/symlink-tree, lib/config-ml.in: Move ... * contrib/multilib: ... in here. * lib/Makefile.am (dist_script_DATA, dist_pkgvdata_DATA): Update. * contrib/multilib/README: New file. * contrib/Makefile.am (EXTRA_DIST): Add the files created or moved in 'contrib/multlib'. * tests/multilib.test: Update and enhance a little. * tests/help-multilib.test: Likewise.
-
Properties
-
README
-
This is the 'contrib' directory of the GNU Automake distribution. Here you'll find additions to the Automake base distribution, in form of makefile fragments, m4 macros, scripts, documentation, et cetera. Such addition that might be useful for a significant percentage of its general audience, but (for one reason or another) are not deemed appropriate for inclusion into the Automake core. There are several reasons for which a feature can be kept in contrib: 1. The long-term usefulness of the feature is debatable and uncertain; on-field and real-word testing are necessary to prove or disprove its usefulness, before the feature can be committed into the Automake core (as doing so too early would later force us to continue the support for backward-compatibility, even if the features proves flawed or fails to attract widespread use). 2. The APIs or overall design of the feature are still unstable, and need on-field testing to iron warts and usability bugs, or uncover potential flaws. 3. The feature was an historical one, mostly obsoleted but still used "here and there" in the wild; so we want to to deprecate it and remove it from the Automake core, but cannot remove it altogether, for the sake of those still-existing usage. So it gets moved in contrib.