gpt4 book ai didi

c++ - makefile可以在C++中强制执行依赖限制吗

转载 作者:塔克拉玛干 更新时间:2023-11-03 07:58:29 25 4
gpt4 key购买 nike

我们正在重构我们的代码库,并试图限制不同组件之间的直接依赖关系。我们的源代码树有几个顶级目录:src/a、src/b 和 src/c。

我们想要执行一组限制:

  • a 中的文件不能依赖于 b 或 c 中的文件
  • b 中的文件可以依赖文件 a 但不依赖 c
  • c中的文件可以直接依赖b中的文件而不是a中的文件

执行第一个很简单。我有一个这样的隐含规则:

build/a/%.o : src/a/%.cpp
$(CXX) -I src/a $(OTHER_FLAGS) -o $@ $<

如果 a 下的文件试图包含来自 b 或 c 的头文件,构建将失败,因为找不到头文件。

第二条规则也有类似的规则,指定src/a和src/b为include目录。问题出现在建筑c。以下是允许的。

src/c/C.cpp
#include "b.h"
void C() { ... }

src/b/b.h
#include "a.h"
class B { ... };

src/a/a.h
class A { ... };

这里,来自 c 的文件包含来自 b 的文件(允许),后者又包含来自 a 的文件(也允许)。我们要防止这样的代码:

src/c/C_bad.cpp
// Direct inclusion of a
#include "a.h"

src/c/c_bad.h
// Direct inclusion of a
#include "a.h"

对于允许编译的情况,在 src/c 中构建文件的编译命令必须包含一个 -Isrc/a,但允许第二种情况也可以编译。

我怀疑我的问题的答案是编写一个脚本来查看编译器生成的依赖项,发现潜在的非法依赖项,然后查看源文件以确定这是否是直接依赖项。有没有一种合理的方法来结合编译器和/或 makefile 结构来做到这一点?

如果重要的话,我们正在使用 GNU Make 3.81 和 g++ 4.5.3,但如果可能的话,我们希望可以移植。

更新

我们正在寻找需要努力违反规则的东西,而不是需要努力遵守规则的东西。 (过去的经验表明后者不太可能奏效。)虽然另一个答案中有一些好主意,但我接受了说写脚本的那个,因为这是最费力的工作大约。

感谢大家的回答。

最佳答案

考虑到您是在现有代码库上应用它,我会选择“验证脚本”方法。

因此,当构建失败时,您不会修改构建过程并一次切断一个依赖项,而是会看到一个不符合要求的文件列表。然后,您可以在考虑“大局”的情况下重构您的代码库,您所做的任何更改都将使用与以前相同的 Makefile 构建,从而简化测试和调试。

重构后,分析脚本可以继续用作合规性检查器来验证 future 的更新。

此类分析的一个可能起点是使用 makedependcpp -MM。例如,使用您在问题中列出的 cpp/h 文件:

[me@home]$ find .../b./b/b.h./a./a/a.h./c./c/C_bad.cpp./c/C.cpp./c/c_bad.h[me@home]$ cpp -MM -Ia -Ib -Ic */*.cpp C_bad.o: c/C_bad.cpp a/a.hC.o: c/C.cpp b/b.h a/a.h[me@home]$ # This also works for header files[me@home]$ cpp -Ia -Ib -Ic -MM c/c_bad.h c_bad.o: c/c_bad.h a/a.h

解析这些输出以确定每个 cpp 文件的依赖关系并标记那些不兼容的应该是相当直接的。

这种方法的缺点是它无法区分直接和间接依赖关系,因此如果这很重要,您可能需要包括一个额外的步骤来检查源代码并挑选出直接依赖关系。

关于c++ - makefile可以在C++中强制执行依赖限制吗,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13919131/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com