我正在开发一个应该进行大量计算的库。它使用GNU autotools构建系统。有一个测试项目链接到该库并运行各种测试过程。每个程序都将结果与MATLAB中预先计算的值进行比较。
我发现测试过程既枯燥又耗时。每次我需要在库中make，sudo make install和测试项目中make，然后运行程序并查看正在发生的事情。
使用autotools将check目标添加到库的标准方法是什么？它应该符合这个要求：
make check并且无需安装库本身即可查看结果。可执行文件应链接到最近编译但尚未安装的共享对象。make check也应运行测试程序。 （不仅编译它）。 make check的结果取决于测试单元程序的返回值。如果测试单元发生故障，make应显示错误。make check，则不应编译任何可执行文件。答案 0 :(得分：3)
由于您已经在使用自动工具，因此您已经拥有了大部分基础设施。我不知道目录布局，但是假设你在顶级SUBDIRS = soroush tests中有： Makefile.am ，或者你可能有 {{1} {/ 1}}目录中的。重要的是在下降到SUBDIRS = tests目录之前存在libtool管理的soroush。
前缀libsoroush.la表示在tests运行之前不应构建那些对象（本例中为check_}。所以在PROGRAM =＆gt; make check
对于每个测试程序，您可以指定： tests/Makefile.am 等。作为快捷方式，如果每个测试只有一个源文件，则可以使用check_PROGRAMS = t1 t2 t3，将隐式为您生成源。到目前为止：
t1_SOURCES = t1.cc AM_DEFAULT_SOURCE_EXT = .cc将构建但不执行这些程序。为此，您需要添加：
AM_CPPFLAGS = -I$(srcdir)/.. $(OTHER_CPPFLAGS) # relative path to lib headers.
LDADD = ../soroush/libsoroush.la
check_PROGRAMS = t1 t2 t3
AM_DEFAULT_SOURCE_EXT = .cc
# or: t1_SOURCES = t1.cc, t1_LDADD = ../soroush/libsoroush.la, etc.
这种方法的真正好处在于，如果将make check构建为共享库，则libtool将使用卸载的库来处理库搜索路径等。< / p>
通常，生成的TESTS = $(check_PROGRAMS)
程序只是一个shell脚本，用于设置环境变量，以便可以执行 real 二进制文件：libsoroush。我只提到这一点，因为使用libtool的全部意义在于你不必担心它是如何完成的。
测试反馈更复杂，具体取决于您的需求。您可以使用并行测试工具，或只是简单的通过/失败反馈。除非测试是一个主要的瓶颈，或者项目很大，否则使用simple（或脚本化）测试会更容易。