如何在公共头文件中正确使用`AC_DEFINE`和`AC_DEFINE_UNQUOTED`定义的变量?
我最近遇到了一个库,它在公共头文件中使用了像HAVE_FEATUREFOO
这样的变量。如何在公共头文件中正确使用`AC_DEFINE`和`AC_DEFINE_UNQUOTED`定义的变量?
它还包括它们的声明#include "config.h"
。这些声明也用于结构声明中,并有条件地删除结构成员。用于库构建的值的不一致性以及依赖程序的构建将导致内存损坏。
因此,使用该库和它的头可能导致以下结果:
#include "config.h"
失败,- 或在运行时内存损坏。
我对自动工具非常陌生,但经过我发现的一些研究后,他们使用AC_DEFINE
or AC_DEFINE_UNQUOTED
进行了定义。而且,config.h
使用AC_CONFIG_HEADERS
生成。
随着进一步的研究,我发现include_HEADERS
,它安装标题。并且,标题config.h
正确安装,如果它被添加到列表中。
是不是正确的做法,通过AC_CONFIG_HEADERS
安装config.h
自动工具生成的头文件?
回答:
生成的config.h
文件不应该包含在用户代码中。这意味着你的库头应该独立于配置测试,你不应该安装config.h
。
回答:
是不是正确的做法,安装AC_CONFIG_HEADERS autotools生成的config.h头文件?
如果其他安装头属于该项目依靠config.h
,那么,config.h
必须安装了。这是唯一可行的方法,因为构建的软件取决于在config.h
中记录的构建时构建系统属性。一般来说,你不能指望在事实之后正确地重新创建。
但安装头不应该#include
一个自动工具config.h
头摆在首位,也不应该依靠一个间接的影响。那么,如果文件名为config.h
的文件不是安装在包含文件搜索路径中,或者是在可能有可能期望有时被添加到包含路径中的任何目录中。碰撞的风险太大 - 在某种程度上,标题名称更为重要,但更重要的是这些标题定义和依赖的宏名称。
底线:Autotools config.h
文件用于构建与之相关联的项目,而不是使用构建的结果。特别是,当这样的项目是或包含一个图书馆时,config.h
不适合图书馆自己的头文件使用任何方式,或者不想被使用该图书馆的代码直接使用。 Autotools提供了不同的机制,通过这些机制可以通过定制用于安装的头文件来记录构建时系统配置。
那么,这就让你对图书馆有什么要求吗?我认为你所描述的问题是代码质量差的一个表现,所以你应该强烈考虑寻找替代方案。您可能会尝试修复该项目,但这不太值得您花时间,尤其是作为Autotools新手。
以上是 如何在公共头文件中正确使用`AC_DEFINE`和`AC_DEFINE_UNQUOTED`定义的变量? 的全部内容, 来源链接: utcz.com/qa/265399.html