问题标签 [autoconf]

应该如何重置 AC_CACHE_CHECK？

在 autoconf 中，我正在检查标题。我添加了一些逻辑来尝试在可能不在默认包含路径中的 std 文件夹中查找头文件。我这样做的方法是首先尝试使用内置的 AC_CHECK_HEADER 查找头文件。如果找不到标头，我修改 CPPFLAGS 并重试。

问题在于 autoconf 的缓存。我想强制检查（或绕过缓存检查。）如果我不强制检查，无论 autoconf 是否找到标头，它都会拉取它在第一次检查中找到的内容，呃。

谢谢，陈兹

我在 autoconf 代码中看到很多关于被 dnl'ed 而不是 dnl'ed 的东西。什么是 dnl'ed？

我有一个小型 ANSI C 应用程序，它可以在不同的测试编译器和平台下干净地编译。它不使用任何预处理器开关或外部依赖项，makefile 类似于：

如果我想以尽可能可移植的源形式分发这个项目，我应该使用 automake/autoconf 包装它吗？这实际上会增加便携性，还是像它一样便携？

我唯一能想到的是它会自动选择系统编译器，但它也会增加很多复杂性。这值得么？

你如何在automake中设置库的顺序？

在我的 am 文件中，我有类似的内容：

现在，当我编译时，我也得到了类似的编译行：

问题是 libmine.a 依赖于 libadhoc.a，因此编译行应该是：

你如何在automake中设置库的顺序？（或者可能是一种解决方法；您如何在编译行中重复所有库。这就是我在自定义 Makefile 中所做的。）

如何阻止 automake 添加 -I。到我的编译行？

似乎 automake 或 libtool 对象总是有一个类似于以下的编译命令：

问题是我有两个同名的头文件....

每个标头都有一个名为 Header 的类，尽管每个标头都位于不同的命名空间中。因此，当我在 ./proj/thisdir 中构建时，“-I”。被包括在内，我无法进入 ./proj/otherdir 中的标题

我不知道如何摆脱最初的“-I”。出现。

有什么提示吗？

谢谢陈兹

问候。我正在尝试创建一个 autoconf 配置脚本，该脚本自动检查要使用的 pthread 选项，理想情况下，在使用 gcc 编译时指定 -pthread。

我希望 AX_PTHREAD 能工作，但似乎都不能在 MacOS 10.6 上工作。

我正在使用来自http://www.nongnu.org/autoconf-archive/ax_pthread.html的 AX_PTHREAD

由于我不明白的原因，它只是不使用 -pthread 选项来构建在 mac 上的脚本。

问题似乎是“无”正在编译而没有错误，因此没有检查 ax_pthread_flags 变量中的其他线程。

因此，我将 -pthread 案例移至“无”案例之前，并将此案例添加到案例语句中：

这似乎可行，但我不确定它是否适用于非 GCC 编译器。而且我什至不确定我是否应该关心。

同样烦人的是 AX_PTHREAD 宏只更新 CFLAGS，而不是 CPPFLAGS。

有没有更好的方法来使用 autoconf 测试 -pthread 选项？

Autoconf 脚本对带有空格的文件名或路径名有问题。例如，

结果（config.log）：

来自 ./configure 的编译命令是ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'，我无法修改它（我也许可以，但以这种方式解决 autoconf 并不是一个通用的解决方案）。

我认为归结为获得一个包含空格的shell变量，以将其解析为单个命令行变量，而不是在空格处拆分。我能想到的最简单的 shell 示例是创建一个带有空格的文件并尝试列出ls一个 shell 变量作为参数ls：

这可行，但是是非法的，因为在 autoconf 中我无法修改 shell 代码：

以下引用事物的尝试均无效：

等等。

这是不可能在 shell 脚本中完成的吗？是否有一个神奇的引用可以将带有空格的 shell 变量扩展为单个命令行参数？

我需要为一个使用基于 autoconf 的系统构建的项目包含GLib头文件以实现可移植性。

如何以可移植的方式安全地导入 GLib 标头？我知道pkg-config，但这并不完全可移植（因为某些系统没有它，我宁愿只依靠 autoconf 进行配置）。

我正在编写自己的单元测试库（使用 autoconf、automake 和 libtool）以更好地满足我的需求（我不需要超大量的功能，只需要一个测试运行程序和断言）。我已经到了它似乎可以使用的地步。

当然，它使用 config.h 来确定要包含的标头。问题是我不确定 config.h 应该去哪里，因为它很容易与其他项目的 config.h 发生冲突，而且它依赖于架构。

我的安装此标头的方法应该是什么？（所有其他标题都需要它）

我有一个 Subversion 项目，它使用 Gnu Autotools（即 automake、autoconf 和 libtool）来管理子文件夹（称为“子包”）中的源代码。子包引用子包根源目录之上的源文件，并且对其他子包是通用的。不幸的是，当运行 'make dist' 来创建发行版 tarball 时，公共源文件不会包含在发行版中。

有没有办法在分发源代码之前使用 autoconf/automake 将这些公共源文件移动到子包的子目录中，并让 makefile 自行调整以正确指向重新定位的源文件？显然，可以在编译之前让 makefile 移动这些源文件，但是对于在 Subversion 存储库中工作，这会导致问题，因为这些移动的文件是受修订控制的，并且很容易意外编辑移动的文件而不是原始文件.