Here is a list of the current programs in the old test suite, and what they test for:
The tests/cdemo subdirectory contains a demonstration of libtool convenience libraries, a mechanism that allows build-time static libraries to be created, in a way that their components can be later linked into programs or other libraries, even shared ones.
The tests matching cdemo-*make.test and cdemo-*exec.test are executed three times, under three different libtool configurations: cdemo-conf.test configures cdemo/libtool to build both static and shared libraries (the default for platforms that support both), cdemo-static.test builds only static libraries (‘--disable-shared’), and cdemo-shared.test builds only shared libraries (‘--disable-static’).
The test cdemo-undef.test tests the generation of shared
libraries with undefined symbols on systems that allow this.
The tests/demo subdirectory contains a demonstration of a trivial
package that uses libtool. The tests matching demo-*make.test,
demo-*exec.test, demo-*inst.test and
demo-*unst.test are executed four times, under four different
libtool configurations: demo-conf.test configures
demo/libtool to build both static and shared libraries,
demo-static.test builds only static libraries
(--disable-shared), and demo-shared.test builds only
shared libraries (--disable-static).
demo-nofast.test configures demo/libtool to
disable the fast-install mode (--enable-fast-install=no).
demo-pic.test configures demo/libtool to
prefer building PIC code (--with-pic), demo-nopic.test
to prefer non-PIC code (--without-pic).
deplibs_check_method to prevent such cases.
This tests checks whether libtool's deplibs_check_method
works properly.
shlibpath_overrides_runpath is
properly set. If the test fails, it will indicate what the variable should
have been set to.
The tests/depdemo subdirectory contains a demonstration of inter-library dependencies with libtool. The test programs link some interdependent libraries.
The tests matching depdemo-*make.test, depdemo-*exec.test,
depdemo-*inst.test and depdemo-*unst.test are executed
four times, under four different libtool configurations:
depdemo-conf.test configures depdemo/libtool to build both
static and shared libraries, depdemo-static.test builds only static
libraries (--disable-shared), and depdemo-shared.test builds
only shared libraries (--disable-static).
depdemo-nofast.test configures depdemo/libtool to
disable the fast-install mode (--enable-fast-install=no).
The tests/mdemo subdirectory contains a demonstration of a package that uses libtool and the system independent dlopen wrapper libltdl to load modules. The library libltdl provides a dlopen wrapper for various platforms (POSIX) including support for dlpreopened modules (see Dlpreopening).
The tests matching mdemo-*make.test, mdemo-*exec.test,
mdemo-*inst.test and mdemo-*unst.test are executed
three times, under three different libtool configurations:
mdemo-conf.test configures mdemo/libtool to build both
static and shared libraries, mdemo-static.test builds only static
libraries (--disable-shared), and mdemo-shared.test builds
only shared libraries (--disable-static).
The tests/mdemo2 directory contains a demonstration of a package
that attempts to link with a library (from the tests/mdemo
directory) that itself does dlopening of libtool modules.
The pdemo-conf.test lowers the max_cmd_len variable in the
generated libtool script to test the measures to evade command line
length limitations.
The tests/tagdemo directory contains a demonstration of a package
that uses libtool's multi-language support through configuration tags.
It generates a library from C++ sources, which is then linked to a C++
program.
The tests/f77demo tests test Fortran 77 support in libtool by
creating libraries from Fortran 77 sources, and mixed Fortran and C
sources, and a Fortran 77 program to use the former library, and a C
program to use the latter library.
The tests/fcdemo is similar to the tests/f77demo directory, except that Fortran 90 is used in combination with the ‘FC’ interface provided by Autoconf and Automake.
The new, Autotest-based test suite uses keywords to classify certain test groups:
-k libtool right before the expansion of the
INNER_TESTSUITEFLAGS variable (without an intervening space, so
you get the chance for further delimitation).
Test groups with the keyword ‘recursive’ should not be denoted with keywords, in order to avoid infinite recursion. As a consequence, recursive test groups themselves should never require user interaction, while the test groups they invoke may do so.
There is a convenience target ‘check-noninteractive’ that runs all tests from both test suites that do not cause user interaction on Windows. Conversely, the target ‘check-interactive’ runs the complement of tests and might require closing popup windows about DLL load errors on Windows.