c - 用户库(C 模块集合): best method to provide overridable configuration per C module?

Question

我想创建并共享一个新的 C 用户库(使用最佳实践)。它是用户程序可以编译和链接的 C 模块的集合。每个模块都有一个默认配置，但用户程序必须能够覆盖默认配置(仅当它愿意时)。另外，不得强制用户程序为其不使用的 C 模块提供配置。

我想将 C 模块文件分组在同一库目录中(例如 module.h、module_cfg.h 和 module.c)，以最大限度地缩短库用户的学习曲线。

这是我对问题的解决方案，但我想知道这是否是不好的形式以及是否有更好的解决方案。

让我们调用新的 C 库 FancyLib 并使用前缀“fl”来防止与其他库或用户代码发生命名空间冲突。图书馆里面有一个timer模块。它有一个默认配置文件，但会被用户提供的配置文件覆盖。库内还有一个名为 foo 的模块。用户程序不使用它。

整个用户项目(包括库)由以下文件组成:

• libs/fl/fl_lib.h
• libs/fl/utils/fl_tmr.h
• libs/fl/utils/fl_tmr_cfg.h <-- 默认
• libs/fl/utils/fl_tmr.c
• libs/fl/utils/fl_foo.h
• libs/fl/utils/fl_foo_cfg.h <-- 默认
• libs/fl/utils/fl_foo.c
• cfg/fl_tmr_cfg.h <-- 覆盖
• src/main.c

src/main.c的内容是:

#include <fl_lib.h>

int main(int argc, char *argv[])
{
    fl_tmr_init();
}

libs/fl/fl_lib.h的内容是:

#ifndef __FL_LIB_H__
#define __FL_LIB_H__

#include <utils/fl_tmr.h>
#include <utils/fl_foo.h>

#endif

libs/fl/utils/fl_tmr.h的内容是:

#ifndef __FL_TMR_H__
#define __FL_TMR_H__

// Include configuration (default or user supplied)
#include <fl_tmr_cfg.h>

void fl_tmr_init(void);

#endif

libs/fl/utils/fl_tmr.c的内容是:

#include "fl_tmr.h" // <-- Need to be quotes

void fl_tmr_init(void)
{
    // Initialise timer
}

libs/fl/utils/fl_foo.h 的内容是:

#ifndef __FL_FOO_H__
#define __FL_FOO_H__

// Include configuration (default or user supplied)
#include <fl_foo_cfg.h>

#endif

编译器的搜索路径指定为“-Icfg -Isrc -Ilibs/fl”。这可确保首先找到用户提供的配置文件 (cfg/fl_tmr_cfg.h) 并覆盖库中的默认文件 (libs/fl/utils/fl_tmr_cfg.h)。

这是最好的方法吗？

此解决方案仅适用于 #include <>使用(带尖括号)，因为它“强制”编译器遵循指定的包含目录优先级，而不使用它在与 *.c 文件相同的目录中首先找到的文件(例如，当 libs/fl/utils/fl_tmr .c 已编译)。

使用#include "" (引号)与 #include <> (尖括号)已深入讨论here ，但我仍然对 this GCC documentation page 感到困惑这让我想到#include <> (尖括号)只能用于系统文件，例如#include <stdio.h>

一个引用示例是 boost library使用 #include <filename>广泛，但有一个异常(exception)。这是一个例子:

boost\libs\math\src\tr1\acosh.cpp:

#include <boost/math/tr1.hpp>
#include <boost/math/special_functions/acosh.hpp> // <-- Angle brackets
#include "c_policy.hpp" // <-- Quotes

注:c_policy.hpp与 acosh.cpp 位于同一目录中

该讨论中提到的一个陷阱是为 #include "" 生成依赖项仅文件，不适用于 #include <>文件。这意味着如果库中的文件发生更改，则需要从头开始重建整个项目。

提前致谢，

彼得

附注任何其他创建良好(嵌入式)C 库的指针/提示/链接/示例将不胜感激。

Answer 1

使用尖括号，#include <mylib.h>要求 IDE(编译器)知道查找 mylib.h 的路径。

使用引号不需要这样做。

使用什么可能取决于您组织文件的方式。如果它们非常本地化并且相对于您的主程序，那么最好使用引号，这使得您的开发目录树更易于传输。