[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-11-g9f8717e
|
From: |
Gary V. Vaughan |
|
Subject: |
[SCM] GNU Libtool branch, master, updated. v2.4.2.444-11-g9f8717e |
|
Date: |
Fri, 03 Jan 2014 04:56:15 +0000 |
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Libtool".
The branch, master has been updated
via 9f8717edbcb133d0aa3fa797e56de83432acd941 (commit)
via 87dfbe2c86c117c14a2cfa053c4b2ca9b02ed3fa (commit)
via 596fd58a484133a433a3fb941ffeaf9c815ac6d8 (commit)
via 4357284ea9899cb50176b75baaeba9ee74687efa (commit)
via b42d44b157e59c1a46ca022ce2a8c402ec790026 (commit)
from e0bb18f4ef8b4ed6ff4453795c96436a68f80501 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 9f8717edbcb133d0aa3fa797e56de83432acd941
Author: Gary V. Vaughan <address@hidden>
Date: Fri Jan 3 17:54:28 2014 +1300
libtool: rearrange header comments for correct version/help extraction.
* m4/libtool.m4 (_LT_COPYING): Rearrange the comments output to
the generated libtool script so that --version and --help behave
the same as pre-funclib.sh revisions.
(_LT_CONFIG_SAVE_COMMANDS): Likewise.
Signed-off-by: Gary V. Vaughan <address@hidden>
commit 87dfbe2c86c117c14a2cfa053c4b2ca9b02ed3fa
Author: Gary V. Vaughan <address@hidden>
Date: Fri Jan 3 17:01:18 2014 +1300
README: Tweak into markdown format and fix some bitrot.
* README: Moved from here...
* README.md: ...to here. Make some changes to be valid markdown
format, and fix some inaccuracies in text that is out of date.
* .gitignore: Add README.
Signed-off-by: Gary V. Vaughan <address@hidden>
commit 596fd58a484133a433a3fb941ffeaf9c815ac6d8
Author: Gary V. Vaughan <address@hidden>
Date: Fri Jan 3 16:45:18 2014 +1300
bootstrap: support automake README requirement.
* gl/build-aux/bootstrap.in (func_ensure_README): New function.
Link missing README to existing alternative naming.
(require_automake_options): New functions. Fetch AM_INIT_AUTOMAKE
options from configure.ac.
(func_reconfigure): If we're using automake, and it's not in
foreign mode, link a README file if possible.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan <address@hidden>
commit 4357284ea9899cb50176b75baaeba9ee74687efa
Author: Gary V. Vaughan <address@hidden>
Date: Fri Jan 3 16:01:53 2014 +1300
configury: use bootstrap ChangeLog management feature.
* gl/build-aux/bootstrap.in (func_autoreconf): Accept an optional
directory argument to pass to $AUTORECONF.
Update doc-comment.
* bootstrap.conf (func_reconfigure): Remove. Don't completely
overwrite bootstrap's func_reconfigure, shadowing auto-ChangeLog
management.
(func_autopoint, func_libtoolize): Overwrite these un-needed
calls instead.
(libtool_autoreconf_libltdl): New hook function to run second
autoreconf in libltdl directory.
(libtool_force_changelog): Remove. This is all handled by
bootstrap's func_reconfigure again.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan <address@hidden>
commit b42d44b157e59c1a46ca022ce2a8c402ec790026
Author: Gary V. Vaughan <address@hidden>
Date: Fri Jan 3 15:55:30 2014 +1300
bootstrap: force remove file droppings from previous run.
Now that we generate bootstrap.new with no write permission,
we have to force remove it before writing now content to the file.
* bootstrap.in (require_bootstrap_uptodate): Remove old
bootstrap.new output.
* bootstrap: Regenerate.
Signed-off-by: Gary V. Vaughan <address@hidden>
-----------------------------------------------------------------------
Summary of changes:
.gitignore | 1 +
README | 326 ---------------------------------------------
README.md | 261 ++++++++++++++++++++++++++++++++++++
bootstrap | 65 ++++++++-
bootstrap.conf | 51 +++-----
gl/build-aux/bootstrap.in | 65 ++++++++-
m4/libtool.m4 | 43 +++----
7 files changed, 419 insertions(+), 393 deletions(-)
delete mode 100644 README
create mode 100644 README.md
diff --git a/.gitignore b/.gitignore
index ae6c32f..c3016d1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -48,6 +48,7 @@
/release
Makefile
Makefile.in
+README
\#*#
_libs
acinclude.m4
diff --git a/README b/README
deleted file mode 100644
index 3ef1bf1..0000000
--- a/README
+++ /dev/null
@@ -1,326 +0,0 @@
-GNU Libtool
-***********
-
-1. Introduction
-===============
-
-This is GNU Libtool, a generic library support script. Libtool hides
-the complexity of using shared libraries behind a consistent, portable
-interface.
-
-Libtool's home page is:
-
- http://www.gnu.org/software/libtool/libtool.html
-
-See the file NEWS for a description of recent changes to Libtool.
-
-Please note that you can build GNU Libtool from this directory using a
-vendor Make program as long as this is an official release tarball;
-otherwise you will need GNU Make for sane VPATH support. See the file
-INSTALL for complete generic instructions on how to build and install
-Libtool. Also, see the file doc/notes.txt for some platform- specific
-information.
-
-See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS)
-for a list of platforms that Libtool already supports.
-
-Please try it on all the platforms you have access to:
-
- * If it builds and passes the test suite ('gmake check'), please send
- a short note to the libtool mailing list <address@hidden> with a
- subject line including the string '[PLATFORM]', and containing the
- details from the end of './libtool --help' in the body.
- * Otherwise, see 'Reporting Bugs' below for how to help us fix any
- problems you discover.
-
-To use Libtool, add the new generic library building commands to your
-Makefile, Makefile.in, or Makefile.am. See the documentation for
-details.
-
-
-2. Reporting Bugs
-=================
-
-If this distribution doesn't work for you, before you report the
-problem, at least try upgrading to the latest released version first,
-and see whether the issue persists. If you feel able, you can also
-check whether the issue has been fixed in the development sources for
-the next release (see 'Obtaining the Latest Sources' below).
-
-Once you've determined that your bug is still not fixed in the latest
-version, please send a full report to <address@hidden>, including:
-
- 1. the information from the end of the help message given by
- './libtool --help', and the verbose output of any failed tests
- (see 'The Test Suites' immediately below);
- 2. complete instructions for how to reproduce your bug, along with
- the results you were expecting, and how they differ from what you
- actually see;
- 3. a workaround or full fix for the bug, if you have it;
- 4. a copy of 'tests/testsuite.log' if you are experiencing failures
- in the Autotest testsuite.
- 5. new test cases for the testsuite that demonstrate the bug are
- especially welcome, and will help to ensure that future releases
- don't reintroduce the problem - if you're not able to write a
- complete testsuite case, a simple standalone shell script is
- usually good enough to help us write a test for you.
-
-If you have any other suggestions, or if you wish to port Libtool to a
-new platform, please send email to the mailing list <address@hidden>.
-
-Please note that if you send us an non-trivial code for inclusion in a
-future release, we may ask you for a copyright assignment (for brief
-details see the 'Copyright Assignment' section on our 'Contributing'
-webpage <http://www.gnu.org/software/libtool/contribute.html>).
-
-
-3. The Test Suites
-==================
-
-Libtool comes with two integrated sets of tests to check that your build
-is sane. You can run both test suites like this, assuming that 'gmake'
-refers to GNU make:
-
- gmake -k check
-
-If you want to run the old testsuite only, do it like this:
-
- gmake check TESTSUITEFLAGS=-V
-
-If you want to run the new testsuite only, do it like this:
-
- gmake check-local
-
-The tests of the old test suite run in groups in the various demo
-subdirectories, so if one of the tests early in a group FAILs, the rest
-of the tests in that group will be SKIPped. If you see a FAIL further
-into a group, even if a test with the same name PASSes in another test
-group, you need to take note of the name of the first test in the group
-if you want to rerun the group with FAILures to get verbose output.
-
-To run a test group of the old test suite in isolation (say, you think
-you have fixed a bug, but don't want to rerun the entire suite), you can
-do it like this:
-
- gmake check TESTSUITEFLAGS=-V TESTS="tests/cdemo-static.test \
- tests/cdemo-static-make.test tests/cdemo-static-exec.test"
-
-Providing that you have a FAIL from the most recent group from a
-particular demo directory (like the cdemo-static.test group above), you
-can explore the state of the directory to help with debugging.
-
-If you wish to report a test group failure to the libtool list, you need
-to send the verbose output of the FAILing group, along with the
-information from the end of '$(top_builddir)/libtool --help' to the bug
-report mailing list, <address@hidden> with a subject line that
-includes the string '[TEST FAILURE]'. The file test-suite.log contains
-the verbose output from all failed tests.
-
-In order to enable debug shell tracing, you can set VERBOSE=debug when
-running the old test suite.
-
-In the long run, Libtool will move to using only the new, Autotest-
-driven testsuite. Its usage is documented in:
-
- info Autoconf 'testsuite Invocation'
-
-but simple help may also be obtained through:
-
- gmake check-local TESTSUITEFLAGS='--help'
-
-For verbose output, add the flag '-v', for running only a subset of the
-independent tests, merely specify them by number or by keyword, both of
-which are displayed with the '--list' flag. For example, the 'libtool'
-keyword is used for the tests that exercise only this script. So it is
-possible to test an installed script, possibly from a different Libtool
-release, with:
-
- gmake check-local \
- TESTSUITEFLAGS="-k libtool LIBTOOL=/path/to/libtool"
-
-Some tests, like the one exercising max_cmd_len limits, make use of this
-to invoke the testsuite recursively on a subset of tests. For these
-tests, the variable INNER_TESTSUITEFLAGS may be used. It will be
-expanded right after the '-k libtool', without separating whitespace, so
-that further limiting of the recursive set of tests is possible. For
-example, to run only the template tests within the max_cmd_len, use:
-
- gmake check-local TESTSUITEFLAGS="-v -x -k max_cmd_len \
- INNER_TESTSUITEFLAGS=',template -v -x'"
-
-If you wish to report test failures to the libtool list, you need to
-send the file 'tests/testsuite.log' to the bug report mailing list,
-<address@hidden>.
-
-
-4. Obtaining the Latest Sources
-===============================
-
-* With the exception of ancient releases, all official GNU Libtool
- releases have a detached GPG signature file. With this you can verify
- that the corresponding file (i.e. without the '.sig' suffix) is the
- same file that was released by the owner of it's GPG key ID. First,
- be sure to download both the .sig file and the corresponding release,
- then run a command like this:
-
- gpg --verify libtool-x.y.z.tar.gz.sig
-
- If that command fails because you don't have the required public key,
- then run this command to import it:
-
- gpg --keyserver keys.gnupg.net --recv-keys 2983D606
-
- and then rerun the 'gpg --verify' command.
-
-* Official stable releases of GNU Libtool, along with these detached
- signature files are available from:
-
- ftp://ftp.gnu.org/gnu/libtool
-
- To reduce load on the main server, please use one of the mirrors
- listed at:
-
- http://www.gnu.org/order/ftp.html
-
-* Alpha quality pre-releases of GNU Libtool, also with detached
- signature files are available from:
-
- ftp://alpha.gnu.org/gnu/libtool
-
- and some of the mirrors listed at:
-
- http://www.gnu.org/order/ftp.html
-
-* Nightly snapshots of the unreleased development trunk of GNU Libtool
- are available from:
-
- http://pogma.com/libtool
-
- These files do not have signatures, but will allow you to easily
- determine whether the most recent development code still exhibits any
- bugs you have discovered, without requiring you to install a complete
- build environment and the extra tools needed to bootstrap a version
- control checkout.
-
-* The master libtool repository is stored in git.
-
- If you are a member of the savannah group for GNU Libtool, a writable
- copy of the libtool repository can be obtained by:
-
- git clone <savannah-user>@git.sv.gnu.org:/srv/git/libtool.git
-
- If you are behind a firewall that blocks the git protocol, you may
- find it useful to use
-
- git config --global url.http://git.sv.gnu.org/r/.insteadof \
- git://git.sv.gnu.org/
-
- to force git to transparently rewrite all savannah git references to
- use http.
-
- If you are not a member of the savannah group for GNU Libtool, you can
- still fetch a read-only copy with either:
-
- git clone git://git.sv.gnu.org/libtool.git
-
- or using the CVS pserver protocol:
-
- cvs -d:pserver:address@hidden:/srv/git/libtool.git \
- co -d libtool HEAD
-
-* Before you can build from git, you need to bootstrap. This requires:
- - Autoconf 2.62 or later
- - Automake 1.11.1 or later
- - Help2man 1.29 or later
- - Xz 4.999.8beta or later (from <http://tukaani.org/xz>)
- - Texinfo 4.8 or later
- - Any prerequisites of the above (such as m4, perl, tex)
-
- Note that these bootstrapping dependencies are much stricter than
- those required to use a destributed release for your own packages.
- After installation, GNU Libtool is designed to work either standalone,
- or optionally with:
- - Autoconf 2.59 or later
- - Automake 1.9.6 or later
-
-* The 'bootstrap' script sets up the source directory for you to hack,
- though it may take quite some time to run. If you don't intend to
- re-run the test suite, you can speed up the 'bootstrap' step by an
- order of magnitude if you call it like this instead:
-
- reconfdirs='. libltdl' ./bootstrap
-
-
-5. Version Numbering
-====================
-
-People have complained that they find the version numbering scheme under
-which libtool is released confusing... so we've changed it!
-
-It works like this:
-
- <major-number>.<minor-number>
-
-Releases with a <major-number> less than 1 were not yet feature
-complete. Releases with a <major-number> of 1 used the old numbering
-scheme that everyone disliked so much. Releases with a <major-number>
-of 2 us the new scheme described here. If libtool ever undergoes a
-major rewrite or substantial restructuring, the <major-number> will be
-incremented again.
-
-If we make a patch release to fix bugs in a stable release, we use a
-third number, so:
-
- <major-number>.<minor-number>.<micro-number>
-
-Version numbers are chosen to make it easy for users to decide two
-things:
-
- Q: How 'developed' is this release?
- A: The higher the number, the better!
- Q: How 'stable' is this release?
- A: - If the <minor-number> is even, it is a stable release, '2.0'.
- - If the <minor-number> is odd, it is a development version with
- new features compared to the last stable release, '2.1a'.
- - If it has an 'odd'[1] letter after the version number, it is a
- snapshot direct from CVS, '2.1a'.
- - If it has an 'even'[1] letter after the version number, it is an
- alpha quality release, '2.1b'.
- - If it has three numbers in the version, it is a patch release,
- fixing bugs from the stable release (with no new features), '2.0.1'.
-
-[1] We always increment the letter in the repository before *and* after
- making a release tarball. This means that "odd" letters
- (a,c,e,g...) only exist in the repository, and "even" letters are
- used instantaneously for an alpha release. Since the odd lettered
- version numbers cover many states of the tree, we also qualify them
- by adding the cvs version of the ChangeLog:
-
- $ libtool --version
- ltmain.sh (GNU libtool 1.1603 2004/09/12 22:02:07) 2.1a
-
- Copyright (C) 2004, 2011-2014 Free Software Foundation, Inc.
- This is free software; see the source for copying conditions. There is NO
- warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-For more details about version numbers, see:
-
- http://www.gnu.org/software/libtool/contribute.html
---
- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
- Foundation, Inc.
- Written by Gary V. Vaughan, 2004
-
- This file is part of GNU Libtool.
-
-Copying and distribution of this file, with or without modification,
-are permitted in any medium without royalty provided the copyright
-notice and this notice are preserved. This file is offered as-is,
-without warranty of any kind.
-
-
-Local Variables:
-mode: text
-fill-column: 72
-End:
-vim:tw=72
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..96898b4
--- /dev/null
+++ b/README.md
@@ -0,0 +1,261 @@
+# GNU Libtool
+
+1. Introduction
+===============
+
+[GNU Libtool][libtool] is a generic library support script.
+[Libtool][] hides the complexity of using shared libraries behind a
+consistent, portable interface.
+
+Libtool's home page is:
+
+ http://www.gnu.org/software/libtool/libtool.html
+
+See the file [NEWS][] for a description of recent changes to Libtool.
+
+Please note that you can build GNU Libtool from this directory using a
+vendor Make program as long as this is an official release tarball;
+otherwise you will need GNU Make for sane VPATH support. See the file
+[INSTALL][] for complete generic instructions on how to build and install
+Libtool. Also, see the file [doc/notes.txt][notes] for some platform-
+specific information.
+
+See the info node (libtool)Tested Platforms. (or the file
+[doc/PLATFORMS][platforms]) for a list of platforms that Libtool already
+supports.
+
+Please try it on all the platforms you have access to:
+
+ * If it builds and passes the test suite (`gmake check`), please send
+ a short note to the [libtool mailing list][libtool list] with a
+ subject line including the string `[PLATFORM]`, and containing the
+ details from the end of `./libtool --help` in the body.
+ * Otherwise, see _Reporting Bugs_ below for how to help us fix any
+ problems you discover.
+
+To use Libtool, add the new generic library building commands to your
+`Makefile`, `Makefile.in`, or `Makefile.am`. See the documentation for
+details.
+
+[install]: http://git.savannah.gnu.org/cgit/libtool.git/tree/INSTALL
+[libtool]: http://www.gnu.org/s/libtool
+[libtool list]: mailto:address@hidden
+[news]: http://git.savannah.gnu.org/cgit/libtool.git/tree/NEWS
+[notes]: http://git.savannah.gnu.org/cgit/libtool.git/tree/doc/notes.texi
+[platforms]: http://git.savannah.gnu.org/cgit/libtool.git/tree/doc/PLATFORMS
+
+
+2. Reporting Bugs
+=================
+
+If this distribution doesn't work for you, before you report the
+problem, at least try upgrading to the latest released version first,
+and see whether the issue persists. If you feel able, you can also
+check whether the issue has been fixed in the development sources for
+the next release (see _Obtaining the Latest Sources_ below).
+
+Once you've determined that your bug is still not fixed in the latest
+version, please send a full report to the libtool [bug mailing list][],
+including:
+
+ 1. the information from the end of the help message given by
+ `./libtool --help`, and the verbose output of any failed tests
+ (see _The Test Suites_ immediately below);
+ 2. complete instructions for how to reproduce your bug, along with
+ the results you were expecting, and how they differ from what you
+ actually see;
+ 3. a workaround or full fix for the bug, if you have it;
+ 4. a copy of `tests/testsuite.log` if you are experiencing failures
+ in the Autotest testsuite.
+ 5. new test cases for the testsuite that demonstrate the bug are
+ especially welcome, and will help to ensure that future releases
+ don't reintroduce the problem - if you're not able to write a
+ complete testsuite case, a simple standalone shell script is
+ usually good enough to help us write a test for you.
+
+If you have any other suggestions, or if you wish to port Libtool to a
+new platform, please send email to the [mailing list][libtool list].
+
+Please note that if you send us an non-trivial code for inclusion in a
+future release, we may ask you for a copyright assignment (for brief
+details see the 'Copyright Assignment' section on our
+[Contributing][contribute] webpage.
+
+[bug mailing list]: mailto:address@hidden
+[contribute]: http://www.gnu.org/software/libtool/contribute.html
+
+
+3. The Test Suite
+=================
+
+Libtool comes an integrated sets of tests to check that your build
+is sane. You can run like this, assuming that `gmake` refers to GNU
+make:
+
+ gmake check
+
+The new, Autotest-driven testsuite is documented in:
+
+ info Autoconf 'testsuite Invocation'
+
+but simple help may also be obtained through:
+
+ gmake check TESTSUITEFLAGS='--help'
+
+For verbose output, add the flag '-v', for running only a subset of the
+independent tests, merely specify them by number or by keyword, both of
+which are displayed with the '--list' flag. For example, the 'libtool'
+keyword is used for the tests that exercise only this script. So it is
+possible to test an installed script, possibly from a different Libtool
+release, with:
+
+ gmake check \
+ TESTSUITEFLAGS="-k libtool LIBTOOL=/path/to/libtool"
+
+Some tests, like the one exercising `max_cmd_len` limits, make use of
+this to invoke the testsuite recursively on a subset of tests. For these
+tests, the variable `INNER_TESTSUITEFLAGS` may be used. It will be
+expanded right after the `-k libtool`, without separating whitespace, so
+that further limiting of the recursive set of tests is possible. For
+example, to run only the template tests within the `max_cmd_len`, use:
+
+ gmake check TESTSUITEFLAGS="-v -x -k max_cmd_len \
+ INNER_TESTSUITEFLAGS=',template -v -x'"
+
+If you wish to report test failures to the libtool list, you need to
+send the file `tests/testsuite.log` to the [bug mailing list][].
+
+
+4. Obtaining the Latest Sources
+===============================
+
+* With the exception of ancient releases, all official GNU Libtool
+ releases have a detached GPG signature file. With this you can verify
+ that the corresponding file (i.e. without the `.sig` suffix) is the
+ same file that was released by the owner of it's GPG key ID. First,
+ be sure to download both the .sig file and the corresponding release,
+ then run a command like this:
+
+ gpg --verify libtool-x.y.z.tar.gz.sig
+
+ If that command fails because you don't have the required public key,
+ then run this command to import it:
+
+ gpg --keyserver keys.gnupg.net --recv-keys 2983D606
+
+ and then rerun the `gpg --verify` command.
+
+* Official stable releases of GNU Libtool, along with these detached
+ signature files are available from:
+
+ ftp://ftp.gnu.org/gnu/libtool
+
+ To reduce load on the main server, please use one of the mirrors
+ listed at:
+
+ http://www.gnu.org/order/ftp.html
+
+* Alpha quality pre-releases of GNU Libtool, also with detached
+ signature files are available from:
+
+ ftp://alpha.gnu.org/gnu/libtool
+
+ and some of the mirrors listed at:
+
+ http://www.gnu.org/order/ftp.html
+
+* The master libtool repository is stored in git.
+
+ If you are a member of the savannah group for GNU Libtool, a writable
+ copy of the libtool repository can be obtained by:
+
+ git clone <savannah-user>@git.sv.gnu.org:/srv/git/libtool.git
+
+ If you are behind a firewall that blocks the git protocol, you may
+ find it useful to use
+
+ git config --global url.http://git.sv.gnu.org/r/.insteadof \
+ git://git.sv.gnu.org/
+
+ to force git to transparently rewrite all savannah git references to
+ use http.
+
+ If you are not a member of the savannah group for GNU Libtool, you can
+ still fetch a read-only copy with either:
+
+ git clone git://git.sv.gnu.org/libtool.git
+
+ or using the CVS pserver protocol:
+
+ cvs -d:pserver:address@hidden:/srv/git/libtool.git \
+ co -d libtool HEAD
+
+* Before you can build from git, you need to bootstrap. This requires:
+ - Autoconf 2.62 or later
+ - Automake 1.11.1 or later
+ - Help2man 1.29 or later
+ - Xz 4.999.8beta or later (from [tukaani.org](http://tukaani.org/xz))
+ - Texinfo 4.8 or later
+ - Any prerequisites of the above (such as m4, perl, tex)
+
+ Note that these bootstrapping dependencies are much stricter than
+ those required to use a destributed release for your own packages.
+ After installation, GNU Libtool is designed to work either standalone,
+ or optionally with:
+ - Autoconf 2.59 or later
+ - Automake 1.9.6 or later
+
+* The `bootstrap` script sets up the source directory for you to hack.
+
+
+5. Version Numbering
+====================
+
+People have complained that they find the version numbering scheme under
+which libtool is released confusing... so we've changed it!
+
+It works like this:
+
+ <major-number>.<minor-number>
+
+Releases with a **major-number** less than 1 were not yet feature
+complete. Releases with a **major-number** of 1 used the old numbering
+scheme that everyone disliked so much. Releases with a **major-number**
+of 2 us the new scheme described here. If libtool ever undergoes a
+major rewrite or substantial restructuring, the **major-number** will be
+incremented again.
+
+If we make a patch release to fix bugs in a stable release, we use a
+third number, so:
+
+ 2.4.2
+
+If we make an alpha quality prerelease, we use a fourth number for the
+number of changsets applied since the version it's based on:
+
+ 2.4.2.418
+
+And finally, if you build an unreleased version it will have a short git
+revision hash string in hexadecimal appended to all of that:
+
+ 2.4.2.418.3-30eaa
+
+--
+ Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
+ Foundation, Inc.
+
+ Written by Gary V. Vaughan, 2004
+
+ This file is part of GNU Libtool.
+
+Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved. This file is offered as-is,
+without warranty of any kind.
+
+
+Local Variables:
+mode: text
+fill-column: 72
+End:
+vim:tw=72
diff --git a/bootstrap b/bootstrap
index f6ea4da..44cd0cd 100755
--- a/bootstrap
+++ b/bootstrap
@@ -2690,6 +2690,14 @@ func_reconfigure ()
{
$debug_cmd
+ $require_automake_options
+
+ # Automake (without 'foreign' option) requires that README exists.
+ case " $automake_options " in
+ " foreign ") ;;
+ *) func_ensure_README ;;
+ esac
+
# Ensure ChangeLog presence.
if test -n "$gnulib_modules"; then
func_ifcontains "$gnulib_modules" gitlog-to-changelog \
@@ -2704,7 +2712,7 @@ func_reconfigure ()
fi
# Released 'autopoint' has the tendency to install macros that have
- # been obsoleted in current 'gnulib., so run this before 'gnulib-tool'.
+ # been obsoleted in current 'gnulib', so run this before 'gnulib-tool'.
func_autopoint
# Autoreconf runs 'aclocal' before 'libtoolize', which causes spurious
@@ -3016,12 +3024,44 @@ EOT
}
-# func_autoreconf
-# ---------------
+# func_ensure_README
+# ------------------
+# Without AM_INIT_AUTOMAKE([foreign]), automake will not run to
+# completion with no README file, even though README.md or README.txt
+# is often preferable.
+func_ensure_changelog ()
+{
+ $debug_cmd
+
+ test -f README || {
+ _G_README=
+ for _G_readme in README.txt README.md README.rst; do
+ test -f $_G_readme && break
+ done
+
+ test -f $_G_readme && $LN_S $_G_readme README
+ func_verbose "$LN_S $_G_readme README"
+ }
+
+ return 0
+}
+
+
+# func_autoreconf [SUBDIR]
+# ------------------------
# Being careful not to re-run 'autopoint' or 'libtoolize', and not to
# try to run 'autopoint', 'libtoolize' or 'autoheader' on packages that
# don't use them, defer to 'autoreconf' for execution of the remaining
# autotools to bootstrap this package.
+#
+# Projects with multiple trees to reconfigure can hook another call to
+# this function onto func_reconfigure:
+#
+# my_autoreconf_foo ()
+# {
+# func_autoreconf foo
+# }
+# func_add_hook func_reconfigure my_autoreconf_foo
func_autoreconf ()
{
$debug_cmd
@@ -3038,7 +3078,7 @@ func_autoreconf ()
$opt_copy || func_append _G_autoreconf_options " --symlink"
$opt_force && func_append _G_autoreconf_options " --force"
$opt_verbose && func_append _G_autoreconf_options " --verbose"
- func_show_eval "$AUTORECONF$_G_autoreconf_options --install" 'exit $?'
+ func_show_eval "$AUTORECONF$_G_autoreconf_options --install${1+ $1}" 'exit
$?'
AUTOPOINT=$save_AUTOPOINT
LIBTOOLIZE=$save_LIBTOOLIZE
@@ -3263,6 +3303,21 @@ func_require_autoheader ()
}
+# require_automake_options
+# ------------------------
+# Extract options from AM_AUTOMAKE_INIT.
+require_automake_options=func_require_automake_options
+func_require_automake_options ()
+{
+ $debug_cmd
+
+ func_extract_trace AM_INIT_AUTOMAKE
+ automake_options=$func_extract_trace_result
+
+ require_automake_options=:
+}
+
+
# require_autopoint
# -----------------
# Skip autopoint if it's not needed.
@@ -3317,6 +3372,7 @@ Please add bootstrap to your gnulib_modules list in
'bootstrap.conf', so that I can tell you when there are
updates available."
else
+ rm -f bootstrap.new
$build_aux/inline-source $build_aux/bootstrap.in > bootstrap.new
if func_cmp_s "$progpath" bootstrap.new; then
@@ -4058,7 +4114,6 @@ func_require_macro_dir ()
# require_makefile_am
# -------------------
# Ensure there is a 'Makefile.am' in the current directory.
-# names an existing file.
require_makefile_am=func_require_makefile_am
func_require_makefile_am ()
{
diff --git a/bootstrap.conf b/bootstrap.conf
index 6365ca6..c8614cb 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -109,37 +109,21 @@ libtool_obsolete_files="
## Override functions. ##
## ------------------- ##
-# func_reconfigure
-# ------------------
-# In addition to needing to autoreconf two directories, Libtool provides
-# 'libtoolize' and doesn't use 'autopoint', so we can use a somewhat
-# simpler 'func_reconfigure' implementation than bootstrap's version.
-func_reconfigure ()
+# func_autopoint
+# --------------
+# Libtool does not use autopoint.
+func_autopoint ()
{
$debug_cmd
+}
- $require_autoheader
- $require_build_aux
- $require_ltdl_dir
- $require_macro_dir
-
- # Only need this from the top level directory
- func_gnulib_tool
-
- export LIBTOOLIZE
- func_verbose "export LIBTOOLIZE='$LIBTOOLIZE'"
-
- my_autoreconf_options=
- $opt_copy || func_append my_autoreconf_options " --symlink"
- $opt_force && func_append my_autoreconf_options " --force"
- $opt_verbose && func_append my_autoreconf_options " --verbose"
-
- func_show_eval "$AUTORECONF$my_autoreconf_options --install ." \
- 'exit $?'
- # Also bootstrap libltdl ready for installation.
- func_show_eval "$AUTORECONF$my_autoreconf_options --install $ltdl_dir" \
- 'exit $?'
+# func_libtoolize
+# ---------------
+# Libtoolize is part of Libtool!
+func_libtoolize ()
+{
+ $debug_cmd
}
@@ -231,16 +215,17 @@ libtool_build_prerequisites ()
func_add_hook func_gnulib_tool libtool_build_prerequisites
-# libtool_force_changelog
-# -----------------------
-# Automake requires that ChangeLog exist.
-libtool_force_changelog ()
+# libtool_autoreconf_libltdl
+# --------------------------
+# Libtldl directory needs to be autoreconfed too.
+libtool_autoreconf_libltdl ()
{
$debug_cmd
- echo "Autogenerated by 'make dist'" > ChangeLog || exit 1
+ # Also bootstrap libltdl ready for installation.
+ func_autoreconf libltdl
}
-func_add_hook func_gnulib_tool libtool_force_changelog
+func_add_hook func_reconfigure libtool_autoreconf_libltdl
# libtool_readme_release_package_substitutions
diff --git a/gl/build-aux/bootstrap.in b/gl/build-aux/bootstrap.in
index 9591384..d596c84 100755
--- a/gl/build-aux/bootstrap.in
+++ b/gl/build-aux/bootstrap.in
@@ -356,6 +356,14 @@ func_reconfigure ()
{
$debug_cmd
+ $require_automake_options
+
+ # Automake (without 'foreign' option) requires that README exists.
+ case " $automake_options " in
+ " foreign ") ;;
+ *) func_ensure_README ;;
+ esac
+
# Ensure ChangeLog presence.
if test -n "$gnulib_modules"; then
func_ifcontains "$gnulib_modules" gitlog-to-changelog \
@@ -370,7 +378,7 @@ func_reconfigure ()
fi
# Released 'autopoint' has the tendency to install macros that have
- # been obsoleted in current 'gnulib., so run this before 'gnulib-tool'.
+ # been obsoleted in current 'gnulib', so run this before 'gnulib-tool'.
func_autopoint
# Autoreconf runs 'aclocal' before 'libtoolize', which causes spurious
@@ -682,12 +690,44 @@ EOT
}
-# func_autoreconf
-# ---------------
+# func_ensure_README
+# ------------------
+# Without AM_INIT_AUTOMAKE([foreign]), automake will not run to
+# completion with no README file, even though README.md or README.txt
+# is often preferable.
+func_ensure_changelog ()
+{
+ $debug_cmd
+
+ test -f README || {
+ _G_README=
+ for _G_readme in README.txt README.md README.rst; do
+ test -f $_G_readme && break
+ done
+
+ test -f $_G_readme && $LN_S $_G_readme README
+ func_verbose "$LN_S $_G_readme README"
+ }
+
+ return 0
+}
+
+
+# func_autoreconf [SUBDIR]
+# ------------------------
# Being careful not to re-run 'autopoint' or 'libtoolize', and not to
# try to run 'autopoint', 'libtoolize' or 'autoheader' on packages that
# don't use them, defer to 'autoreconf' for execution of the remaining
# autotools to bootstrap this package.
+#
+# Projects with multiple trees to reconfigure can hook another call to
+# this function onto func_reconfigure:
+#
+# my_autoreconf_foo ()
+# {
+# func_autoreconf foo
+# }
+# func_add_hook func_reconfigure my_autoreconf_foo
func_autoreconf ()
{
$debug_cmd
@@ -704,7 +744,7 @@ func_autoreconf ()
$opt_copy || func_append _G_autoreconf_options " --symlink"
$opt_force && func_append _G_autoreconf_options " --force"
$opt_verbose && func_append _G_autoreconf_options " --verbose"
- func_show_eval "$AUTORECONF$_G_autoreconf_options --install" 'exit $?'
+ func_show_eval "$AUTORECONF$_G_autoreconf_options --install${1+ $1}" 'exit
$?'
AUTOPOINT=$save_AUTOPOINT
LIBTOOLIZE=$save_LIBTOOLIZE
@@ -929,6 +969,21 @@ func_require_autoheader ()
}
+# require_automake_options
+# ------------------------
+# Extract options from AM_AUTOMAKE_INIT.
+require_automake_options=func_require_automake_options
+func_require_automake_options ()
+{
+ $debug_cmd
+
+ func_extract_trace AM_INIT_AUTOMAKE
+ automake_options=$func_extract_trace_result
+
+ require_automake_options=:
+}
+
+
# require_autopoint
# -----------------
# Skip autopoint if it's not needed.
@@ -983,6 +1038,7 @@ Please add bootstrap to your gnulib_modules list in
'bootstrap.conf', so that I can tell you when there are
updates available."
else
+ rm -f bootstrap.new
$build_aux/inline-source $build_aux/bootstrap.in > bootstrap.new
if func_cmp_s "$progpath" bootstrap.new; then
@@ -1724,7 +1780,6 @@ func_require_macro_dir ()
# require_makefile_am
# -------------------
# Ensure there is a 'Makefile.am' in the current directory.
-# names an existing file.
require_makefile_am=func_require_makefile_am
func_require_makefile_am ()
{
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 900b172..ce58f31 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -8,33 +8,27 @@
# modifications, as long as this notice is preserved.
m4_define([_LT_COPYING], [dnl
-# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006, 2007, 2008, 2009, 2010, 2011 Free Software
-# Foundation, Inc.
-# Written by Gordon Matzigkeit, 1996
-#
-# This file is part of GNU Libtool.
+# Copyright (C) 2014 Free Software Foundation, Inc.
+# This is free software; see the source for copying conditions. There is NO
+# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+# GNU Libtool is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of of the License, or
+# (at your option) any later version.
#
-# GNU Libtool is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program or library that is built
+# using GNU Libtool, you may include this file under the same
+# distribution terms that you use for the rest of that program.
#
-# As a special exception to the GNU General Public License,
-# if you distribute this file as part of a program or library that
-# is built using GNU Libtool, you may include this file under the
-# same distribution terms that you use for the rest of that program.
-#
-# GNU Libtool is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# GNU Libtool is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
-# along with GNU Libtool; see the file COPYING. If not, a copy
-# can be downloaded from http://www.gnu.org/licenses/gpl.html, or
-# obtained by writing to the Free Software Foundation, Inc.,
-# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
])
# serial 58 LT_INIT
@@ -715,12 +709,13 @@ _LT_CONFIG_SAVE_COMMANDS([
cat <<_LT_EOF >> "$cfgfile"
#! $SHELL
-
-# `$ECHO "$ofile" | sed 's%^.*/%%'` - Provide generalized library-building
support services.
# Generated automatically by $as_me ($PACKAGE) $VERSION
# Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
# NOTE: Changes made to this file will be lost: look at ltmain.sh.
-#
+
+# Provide generalized library-building support services.
+# Written by Gordon Matzigkeit, 1996
+
_LT_COPYING
_LT_LIBTOOL_TAGS
hooks/post-receive
--
GNU Libtool
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [SCM] GNU Libtool branch, master, updated. v2.4.2.444-11-g9f8717e,
Gary V. Vaughan <=