我想包含 #define 文件中的 h s,以便使用 Doxygen 解析所有其他文件。

项目背景:

我的 C 项目在它的构建命令中包含一个头文件 config.h

它还在同一个构建命令上定义了一个目标 MODEL_A
config.h 根据正在构建的目标创建定义(与 MODEL_AMODEL_B 的定义列表不同):

#if defined(MODEL_A)
#define HAS_FUNCTIONALITY_1
#define HAS_FUNCTIONALITY_2
#elif defined(MODEL_B)
#define HAS_FUNCTIONALITY_3
#define HAS_FUNCTIONALITY_4
#endif

我的 Doxygen 问题:

我尝试使用 Doxygen 生成文档。我在 Doxyfile 中有:
# including of config.h to INPUT seems necessary.
INPUT = ./source/config.h \
    ./source
ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = NO
INCLUDE_PATH = ./source
INCLUDE_FILE_PATTERNS = ./source/config.h
PREDEFINED = MODEL_A

依赖于定义 HAS_FUNCTIONALITY_x 的代码未包含在文档中,就好像预处理器没有获得 config.h 中的定义一样。

我目前的发现:

我在doxygen -d Preprocessor的帮助下检查了预处理程序的输出,可以看到:
  • ./source/config.h 首先被解析,并根据 MODEL_A 正确解析(我可以在预处理器输出中看到正确的 #defines)。预处理器输出中的#define HAS_FUNCTIONALITY_1数字。
  • C 文件的预处理依赖于 HAS_FUNCTIONALITY_1 就像未定义一样。

  • 在 Doxyfile 的 HAS_FUNCTIONALITY_1 字段中定义 PREDEFINED 会按预期工作。这不是一个实用的解决方案,但仍然很有趣。

    当预处理器处理所有后续 C 文件时,如何确保首先从 #define 预处理的 config.h 行保持定义?

    最佳答案

    展示 C 代码本身可能对您有益。一般来说,Doxygen 运行一个标准的预处理器——即渲染的代码应该与编译器预处理的代码相同。为了在代码中实现等价的 #define HAS_FUNCTIONALITY_1 - 它必须被定义。
    我从您不愿意将它添加到 doxygen 配置中了解到,它是在项目的其他地方(或者可能是 Makefile)中定义的,这就是实际代码的行为就像它被定义一样的原因。
    如果是这种情况,除了更多的预处理器技巧或简单地将它添加到 doxygen 配置文件之外,我看不到其他合理的解决方法。

    关于c - 包含一个头文件,用于使用 Doxygen 预处理器解析所有其他文件,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/15544721/

    10-11 23:03
    查看更多