我想将cpputest作为git子模块包含在我的项目的源代码树中,但我对autotools并不十分熟悉。
我一直在看这一页作为指南
我已经创建了下面的Makefile,cpputest在它下面的一个子目录中:
CPPUTEST_BUILD_DIR := cpputest/cpputest_build
CPPUTEST_LIBS := \
$(CPPUTEST_BUILD_DIR)/libCppUTest.a \
$(CPPUTEST_BUILD_DIR)/libCppUTestExt.a
CPPUTEST_TESTS := \
$(CPPUTEST_BUILD_DIR)/CppUTestTests \
$(CPPUTEST_BUILD_DIR)/CppUTestExtTests
cpputest: \
cpputest/configure \
$(CPPUTEST_BUILD_DIR)/Makefile \
$(CPPUTEST_LIBS) \
$(CPPUTEST_TESTS)
cpputest/configure: cpputest/configure.ac cpputest/autogen.sh
cd cpputest && ./autogen.sh
cpputest/cpputest_build/Makefile: cpputest/configure
cd $(CPPUTEST_BUILD_DIR) && ../configure
$(CPPUTEST_LIBS): $(CPPUTEST_BUILD_DIR)/Makefile
cd $(CPPUTEST_BUILD_DIR) && make
$(CPPUTEST_TESTS): $(CPPUTEST_LIBS)
cd $(CPPUTEST_BUILD_DIR) && make tdd运行这个makefile可以做我想做的事情,但我不确定依赖关系有多强。除了一条干净的规则之外,我还有什么要考虑的吗?
这是我在约翰·博林格的回答之后的最后一个Makefile。
它位于CppUTest目录的根目录中。
# This makefile will generate a platform specific makefile, build CppUTest
# library outputs, and build and run tests on CppUTest.
BUILD_DIR := cpputest_build
LIBS := $(BUILD_DIR)/lib/libCppUTest.a $(BUILD_DIR)/lib/libCppUTestExt.a
TESTS := $(BUILD_DIR)/CppUTestTests $(BUILD_DIR)/CppUTestExtTests
# All builds both libraries, to build and run all of the tests for CppUTest use
# the phony target run_tests.
all: $(LIBS)
.PHONY: all run_tests clean FORCE
# The Makefile rule depends on the "configure" shell script existing. If
# CppUTest is updated from upstream or configure doesn't exist then run
# autogen.sh or uncomment the rule below. All of the outputs autogen.sh should
# be tracked in the develop branch.
#
#configure: configure.ac autogen.sh
# ./autogen.sh
$(BUILD_DIR)/Makefile: configure
mkdir -p $(BUILD_DIR) && cd $(BUILD_DIR) && ../configure
$(LIBS) : $(BUILD_DIR)/Makefile FORCE
cd $(BUILD_DIR) && make $(subst $(BUILD_DIR)/,,$@)
$(TESTS) : $(BUILD_DIR)/Makefile FORCE
cd $(BUILD_DIR) && make $(@F)
run_tests: $(TESTS)
for test in $(TESTS); do $$test -c || exit 1; done
clean:
rm -rf $(BUILD_DIR)发布于 2020-03-09 19:44:12
除了一条干净的规则之外,我还有什么要考虑的吗?
TL;DR:您应该预先运行ccptest的autogen.sh脚本,并在发行版中包括所有的结果文件以及所有其他文件。然后,您也可以考虑省略构建cpputest/configure的规则(我本人确实会忽略它)。
Cpputest显然遵循了最近从源代码管理中省略Autotools生成的文件的趋势。从表面上看,这是有意义的,因为这些文件确实可以从从源代码管理中获得的其他文件中生成。从源代码管理系统作为项目维护和开发工具的角度来看,这是很好的。但是,对于作为分发工具的源代码管理,它是而不是。
Autotools的设计目标之一是,它们本身仅供项目维护人员使用。运行它们并不打算成为常规构建过程的一部分,比如那些只想构建和运行软件的人。因此,Autotools构建系统自己编写的发行包包含了实现这一目标所需的所有比特:configure脚本、支持实用程序脚本、Makefile.in文件,有时还有其他一些杂项文件。这是打算分发的形式。
在这种情况下,与许多项目相比,Autotools上的兼容性压力更小,而且实际上,这体现在不同AT版本之间的兼容性较弱。如果您使用与项目维护人员自己不同版本的AT构建构建系统,那么您可能会遇到错误。您肯定会得到一个与维护人员使用的构建系统有一定区别的构建系统。通常情况下,结果仍然是没有问题的项目,但有时不会。所以帮你自己个忙,避开这个问题。
运行这个makefile可以做我想做的事情,但我不确定依赖关系有多强。
在我看来,makefile本身很不错。我看到的主要批评是
cpputest/cpputest_build/Makefile的规则逐字逐句地列出目录部分,而不是使用$(CPPUTEST_BUILD_DIR)变量。cpputest目标的先决条件列表不应包括cpputest/configure或$(CPPUTEST_BUILD_DIR)/Makefile。这些是构建过程所必需的,这是偶然的,并且已经被那些被列为直接依赖于它们的目标的先决条件的工件所处理。作为风格、可维护性和一般良好实践的问题,make规则应该只列出目标的直接先决条件。不过,既然我建议您分发构建系统组件,而不是让每个人重新构建它们,我也会删除构建cpputest/configure的规则。如果您遵循我的建议,那么您将分发一个预构建的,这样用户就不需要构建它了。省略规则并将cpputest/configure从出现在其中的先决条件列表中删除,将消除在时间戳被乱码的情况下所有东西掉落的轻微风险,有时在复制源树时也会发生这种情况。
至于clean规则,由于您在顶级make的控制下执行cpputest配置,相应的清理方法将是cd $(CPPUTEST_BUILD_DIR); make distclean。但是,由于您正在执行一个源代码外的构建,您还可以选择只递归地删除build目录。但是,请注意,如果您坚持将autogen.sh作为构建过程的一部分运行,则生成的文件不限于构建目录。在这种情况下,相应的clean可能涉及到make maintainer-clean。
https://stackoverflow.com/questions/60605797
复制相似问题