我这样做的方式确实是创建一个包装文件(我通常称之为global.h
)读起来像这样。
#ifndef MY_PROJECT_GLOBAL_H
#define MY_PROJECT_GLOBAL_H
#include <config.h>
/* Maybe other global definitions… */
#endif
请注意,受到推崇的 https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers way to #include
the config.h
文件是通过<config.h>
not "config.h"
所以它可以更好地与VPATH
builds.
那么,所有的source我的项目中的文件#include
this global.h
标题作为他们的第一个#include
并且不关心config.h
. A header文件不应该#include
config.h
因为这会导致不良名称冲突。实际上,如果您坚持这个准则,您的代码也应该可以在没有#include
配置头中的保护。
关于OP评论的更新
或者:如何在标头中使用配置结果?
如果您的标头需要根据结果声明不同的内容configure
脚本时,您有多种选择,但没有一个是完美的。
对于内部标头,没有问题。他们只是依赖于宏#define
d 没有#include
任何东西。如果(按照建议)所有源文件都有效,则此方法有效#include
(也许是间接的,如上所示)config.h
before任何其他标头。
如果要公开安装标头,这不是一个很好的解决方案。对于那些使用 Autoconf 的用户来说,情况不会那么糟糕,尽管即使是那些人也必须记住要在他们的文件中放置哪些检查。configure.ac
文件。对于不使用Autoconf的用户来说,情况会很糟糕。如果您只有几个开关(例如Glibc的fature测试宏 https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#Feature-Test-Macros),可以要求您的用户#define
他们之前#include
ing 你的标题,但如果你需要很多,这不是一个真正的选择。更不用说您将以这种方式向用户公开大量实现细节。
如果您需要做的只是根据您正在构建的平台进行分支,您可以探测一些预定义的宏,例如__linux
or _WIN32
。有的是升压预定义 http://www.boost.org/doc/libs/1_57_0/libs/predef/doc/html/index.html旨在通过提供更高级别的抽象来使这些检查更加方便的库。该库与 C 和 C++ 类似,但当然,它为您的项目添加了额外的依赖项。
最后,你可以制作一个版本config.h
使用特定于您的项目的宏前缀。有贡献 https://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html在 Autoconf 宏存档中,它正是为您做的。一个最小的例子可能是这样的。
AC_PREREQ([2.69])
AC_INIT([example-project], [1.0], [[email protected] /cdn-cgi/l/email-protection])
AC_CONFIG_SRCDIR([example.c])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADERS([config.h])
AX_PREFIX_CONFIG_H([public_config.h], [EXAMPLE_PROJECT], [config.h])
AC_PROG_CC
AC_OUTPUT
将此另存为configure.ac
, 下载ax_prefix_config_h.m4来自 Autoconf 宏存档 http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_prefix_config_h.m4并将其放在子目录中m4
然后运行autoreconf && ./configure
。它将创建正常的config.h
另外public_config.h
在后一个文件中,所有宏都带有前缀EXAMPLE_PROJECT_
。文件public_config.h
(其中还有#include
顺便说一下,防护装置)可以安装并且#include
如果需要的话,可以在项目的公共头文件中添加 d 。