问题标签 [autotools]

我的目标是将所有目标文件构建在 .objs 目录而不是 Makefile 的根目录中，并将二进制文件（和库）复制到项目的bin/目录中。但我一直找不到任何资源来解释如何做到这一点。我该怎么做呢？

这是我的 configure.ac 和src/Makefile.am - 对于两个引用的共享库，我有类似的 Makefile.am 文件。它们编译，并在将它们复制到bin/目录后正常工作。我只是想自动化这个过程。

配置.ac

src/Makefile.am

所以，我的问题是如何为每个 Makefile 的编译结果指定输出目录（我希望它们被复制到bin/，并且目标文件在每个项目的.obj中而不是在 Makefile 的根目录中.

感谢您迄今为止的帮助。这个网站是一个很好的资源，我从已经提供的链接中学到了很多东西。

我正在 GNU/Linux 上开发一个 C++ 项目，我正在寻找一种方法来使用 Autotools 测试 IBM Informix 库的存在性和可用性 - 即编辑一个configure.in. 我没有使用 Autotools 的经验，所以基本上我是从项目的configure.in et al 中学习的。脚本和复制和更改我觉得需要更改的地方。IOW，我一直在改编configure.in.

到目前为止，我一直在成功地使用AC_CHECK_LIBinconfigure.in来测试某个库是否既存在又可用。但这似乎只适用于具有函数的库，而不是类。即，在测试 Informix 的libifc++.so库时失败：

我也尝试过使用其他组合，例如ITString::ITString等。

我没有在 Informix 的 API 中找到“纯”函数（即，在 C++ 类中没有上下文的函数）。所以我希望要么有一种AC_CHECK_LIB在这种情况下使用的方法，要么有另一个autoconf/ configure.in“命令”用于这个特定用途。

提前感谢您的反馈。

在我的公司，我目前正在deb从第三方库中创建一个 Debian 软件包。该库是使用 Autotools 构建的。我以前从未使用过 Autotools，我遇到了一些困难。库源包含文件和configure.in目录。我可以使用以下顺序构建库：Makefile.amm4/

在debian/rules文件中我想使用 CDBS。我写了这个：

但它不起作用。它抱怨configure文件丢失。没错，因为 Autotools 类希望这个文件存在。但它不在那里，有人必须先打电话autoconf和朋友！

为什么 Autotools CDBS 类不让我autoconf和朋友打电话？我该如何规避它？

题外话：

当我使用一个程序时，我不会每次都编译它，我编译一次并重用二进制文件。

当人们安装软件时，他们不会自己编译，维护者编译一次，人们会重复使用二进制包。

维护者在编译包时，不会configure每次编译都创建脚本，上游作者创建一次，维护者可以复用。

最后一句是真的吗？因为在我看来，Autotools CDBS 类的作者似乎假设了这样的事情——他们假设configure存在，并在为不同的架构编译包时重用它。我对吗？

一方面，如果configure可以生成，它不应该出现在任何地方——如果你需要它，你可以从其他文件生成。另一方面，Autotools CDBS 类的作者一定有一些理由以这种方式实现它，而不是另一种方式。

概括：

• 如何处理上述 Autotools CDBS 类问题？
• 我多久再生一次configure？（在一般情况下以及在构建 Debian 软件包时。）

我编写了一个依赖于 libxml++ 和 curl 的库，我很难弄清楚如何AC_CHECK_LIB在我编写的另一个包中的库上使用。新包的config.log文件表明存在对curl_*和的未定义引用xmlpp::*。

我已经PKG_CHECK_MODULES在我的最新包中设置了 libxml++ 和 curl，并且这些都可以工作，但它们显然不能用于AC_CHECK_LIB调用我自己的库。（在检查我自己的库之前，我检查了 libxml++ 和 curl）

更新：第一个问题解决了，第二个在这篇文章的底部描述。

UPDATE2：第二个问题也解决了。

我正在尝试学习如何为一个非常简单的 GTK+2 C 应用程序设置 GNU 构建工具（autoconf/automake）。我已经按照这个教程和这个处理子目录的教程，但是我遇到了一个问题，我的源目录（在 src 子目录中）没有生成 Makefile，尽管父目录的 Makefile 正在生成。

首先，这是我的文件夹结构：

以下是重要文件的内容：

应用程序/configure.ac：

应用程序/Makefile.am：

应用程序/src/Makefile.am：

Here is what happens when I run the following commands:

When I check, the main app folder gets a Makefile and Makefile.in, but the src folder still only has the Makefile.am. Any ideas?

UPDATE: I made the changes mentioned by adl, namely, I removed the square brackets and comma from the AC_CONFIG_FILES command and removed the app name/version from the AM_INIT_AUTOMAKE command. I also changed the app_LDADD command in src/Makefile.am to app_LDFLAGS. This has fixed my initial problem of not getting through a configure, but now it isn't looking for the gtk libraries. When I do a make I get something like the following:

Here is what I get with pkg-config:

I'm pretty sure I'm doing something wrong in my src/Makefile.am, but I don't know what. If it helps, my configure script does not appear to be looking for any gtk libs.

UPDATE2:

So the basic solution for the problem in update1 seems to be that I needed to add the following check to my configure.ac file:

This gets added to the checks for programs section under AC_PROG_CC. What this does is tell configure to check for the gtk+-2.0 library. The upper case GTK seems to be an arbitrary variable name, and the CFLAGS, LIBS, and LDFLAGS (and probably more) gets added to it dynamically so that you can generate the PACKAGE_* variables. The AC_SUBST seems to make it so you can access the PACKAGE* variables in your Makefile.am's. FYI, the -export-dynamic flag is added so that you can use glade/gtkbuilder files (I'm sure there are other reasons, but I'm still at a very basic level of understanding).

In src/Makefile.am, you should have:

This seems to be all you need for a basic gtk+-2.0 C app. It has actually inspired me to write a simple tutorial for setting up a C gtk app that uses autotools. There is a definite lack of recent beginner documentation/information in this field.

我正在将现有库（libtcod）直接转换为 Autotools（为了 OS X 的快乐）。不幸的是，当我将我Makefile.am的lib_LIBRARIES规则切换到lib_LTLIBRARIES时，构建会从成功变为 un。摘自以下输出：

src/Makefile.am看起来像这样：

src/.deps包含：

我在这里犯了一个明显的错误，还是应该这样做？

我正在尝试挖掘一个基于自动工具的项目，实际上有点大。我正在处理它的一小部分，一个子目录。我需要在这个小部分中不断添加/移动/删除文件和目录。

每次在顶层运行 ./configure 不仅耗时，而且会导致整个对象树变得无效（对这些术语感到抱歉，但我对此有点陌生）。所以我想出了如何从 Makefile.am 重新生成 Makefile.in（通过运行 automake path/to/my/part），我想出了如何在构建树中从 Makefile.in 重新生成 Makefile（通过运行 ./config.status路径/到/我/部分）。但是我仍然无法弄清楚：如何重新生成所有依赖文件（构建树中每个子目录中的.deps/*.Plo）。确实，再次运行configure 解决了这个问题。所以，我的问题是：如何在不再次运行 configure 的情况下重新生成依赖文件？提前致谢。

我正在尝试创建一个 Vala 项目，看看我喜欢用这种语言开发作为 Mono 的可能替代品。我认为 automake 的东西可以用来生成一个包含所有必要文件的项目模板（没有我的 .vala 代码）。任何帮助，将不胜感激。

我希望我的代码可以使用 Intel 编译器或 gcc/g++ 编译，具体取决于配置参数。这可能吗？我需要在 configure.ac 和 Makefile.am 文件中添加什么来实现这一点？

我们研究组的部分程序具有ctemplate库提供的辅助功能。在我们过时的集群上，由于编译，我们无法构建软件，所以我想分离这个功能并通过一个标志来控制它是否包含configure，例如--disable-ctemplate.

该软件是用 C++ 编写的，使用 Autotools 构建系统——我对这两个系统都没有太多经验。我的理解是，要完成这个任务，我需要做到以下几点：

1. 通过AC_ARG_ENABLE在configure.ac.

2. 围绕使用该库的代码以及调用该代码的任何代码添加一些#ifdef（或可能的）语句。#ifndefctemplate

我认为第一步看起来像这样：

虽然我不知道逻辑是否正确，因为我已经从使用--enable-FLAG而不是--disable-FLAG.

对于第二步，我将把部分包装在预处理器标志中，例如

如果我这样做了，这会正确地“连接”一切configure --disable-ctemplate吗？

另外，这样能保证程序不进入ctemplate库编译吗？如果没有，那么这一切都是徒劳的；我必须阻止ctemplate库和依赖组件的编译。

我将重申我对 C++ 和 Autotools 都不熟悉；我采取了一种非常幼稚的第一种方法来解决这个问题。如果您在这方面有经验，我非常感谢您的更正和您可以提供的任何解释。