mirror of
git://git.savannah.gnu.org/libtool.git
synced 2024-11-27 06:09:57 +08:00
ac40b5f37a
* configure.ac: Ensure to_host_file_cmd is available to Makefile. * TODO: Document QoI issue with file name conversion functions. * libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New function sets libtool variable $to_host_file_cmd, and employs cache. (_LT_SETUP): Require it. * tests/testsuite.at: Ensure to_host_file_cmd is passed as a variable setting on the configure line for (new testsuite) tests. * Makefile.am (TESTS_ENVIRONMENT): Ensure to_host_file_cmd is included so that it is passed to (old testsuite) tests. * libltdl/config/general.m4sh: Define $lt_sed_naive_backslashify here. * libltdl/config/ltmain.m4sh ($to_host_file_cmd, $to_host_path_cmd): New variables. (func_cygpath): New function. (func_init_to_host_path_cmd): New function. (func_to_host_path): Renamed to... (func_to_host_file): Refactored to... (now uses $to_host_file_cmd). (func_convert_core_file_wine_to_w32): Here. New function. (func_convert_core_msys_to_w32): Here. New function. (func_convert_file_check): Here. New function. (func_convert_file_noop): Here. New function. (func_convert_file_msys_to_w32): Here. New function. (func_convert_file_cygwin_to_w32): Here. New function. (func_convert_file_nix_to_w32): Here. New function. (func_convert_file_msys_to_cygwin): New function. (func_convert_file_nix_to_cygwin): New function. (func_to_host_pathlist): Renamed to... (func_to_host_path): Refactored to... (now uses $to_host_path_cmd and func_init_to_host_path_cmd). (func_convert_path_check): Here. New function. (func_convert_path_front_back_pathsep): Here. New function. (func_convert_core_path_wine_to_w32): Here. New function. (func_convert_path_noop): Here. New function. (func_convert_path_msys_to_w32): Here. New function. (func_convert_path_cygwin_to_w32): Here. New function. (func_convert_path_nix_to_w32): Here. New function. (func_convert_path_msys_to_cygwin): New function. (func_convert_path_nix_to_cygwin): New function. Signed-off-by: Charles Wilson <libtool@cwilson.fastmail.fm> |
||
---|---|---|
doc | ||
libltdl | ||
tests | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
AUTHORS | ||
bootstrap | ||
ChangeLog | ||
ChangeLog.1996 | ||
ChangeLog.1997 | ||
ChangeLog.1998 | ||
ChangeLog.1999 | ||
ChangeLog.2000 | ||
ChangeLog.2001 | ||
ChangeLog.2002 | ||
ChangeLog.2003 | ||
ChangeLog.2004 | ||
ChangeLog.2005 | ||
ChangeLog.2006 | ||
ChangeLog.2007 | ||
ChangeLog.2008 | ||
ChangeLog.2009 | ||
clcommit.m4sh | ||
configure.ac | ||
COPYING | ||
HACKING | ||
libtoolize.m4sh | ||
ltmain.c | ||
Makefile.am | ||
Makefile.maint | ||
NEWS | ||
PORTING | ||
README | ||
README.alpha | ||
THANKS | ||
TODO |
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. To use Libtool, add the new generic library building commands to your Makefile, Makefile.in, or Makefile.am. See the documentation for details. 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. See the file INSTALL for generic instructions on how to build and install Libtool. Please see the file doc/notes.txt for some platform-specific information. Please note that you need GNU make to build Libtool. See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS) for a list of platforms that Libtool supports. 2. Reporting Bugs ================= If you have any suggestions or bug reports, or you wish to port Libtool to a new platform, please send electronic mail to the libtool mailing list <libtool@gnu.org> or bug reports to <bug-libtool@gnu.org>. Be sure to send us your information from the end of the help message given by `./libtool --help'. 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 TESTS="tests/cdemo-static.test tests/cdemo-static-make.test \ tests/cdemo-static-exec.test" \ TESTSUITEFLAGS=-V 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, <bug-libtool@gnu.org> 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, <bug-libtool@gnu.org>. 4. 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 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