问题标签 [autoconf]

我正在 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 软件包时。）

我知道如何构建项目或如何使用 autoconf 创建库。

我想要实现的是生成一个静态库并使用该库在单个 configure/make/make install 运行中构建一个项目。

我希望将一些源文件放入库中，其余的则使用该库进行编译。

如何修改 makefile.am 文件和 configure.ac 以使其正常工作？

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

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.

我目前在我的 autotoolset 项目中有 10 个测试。每当我对我的一个 src/ 文件进行更改并重新编译时，都会重新构建和链接每个测试。这开始对我的开发时间产生相当大的影响。

使用 GNU autotoolset 有条件地构建二进制程序、测试或其他方式的最佳方法是什么？例如，如果我在 test/check_curl_requestheaders.cc 中工作，并且我进行了更改，我只想重新编译库，然后重新编译一个测试，而不需要重新编译其他二进制文件。

我看到有人提到使用 automake 条件（如 WANTS_XXX），但我不能 100% 确定这是我正在寻找的，也不确定 autoconf 将如何配置它。

我有点希望最终会看起来像这样：

或者

指针？

编辑我没有在每次制作之前进行配置。check_curl_requestheaders如果我对, only进行更改，check_curl_requestheaders则会按预期进行重建。问题是，如果我正在处理库的 RequestHeaders 部分，并更改为 src/curl/requestheaders.cc，则所有测试和其他二进制文件都会重新构建，而不仅仅是check_curl_requestheaders. 这花费的时间太长了，而这正是我试图避免的。如果我有十几个二进制文件，有没有办法只重建其中一个？

在一个项目中，我noinst_PROGRAM定义了两个 's。其中一个工作得很好，但另一个给我以下信息：

/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar：符号查找错误：/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar：未定义符号：_ZN5gdata7service7ServiceD1Ev

我一直在查看我的 Makefile.am 文件，但找不到任何我错过的东西。该应用程序编译正确，所以我猜这意味着正确找到了头文件，但由于某种原因我gdata::service::Service没有包含在 src/libgdata.la 库中。

我的假设可能是正确的吗？src/libgdata.la 库中定义的其他类似乎可用。“make”的输出表明 Service.cc 文件正在正确编译......我应该在哪里确定它是否包含在最终库中的任何指针？

编辑：

根据迄今为止提供的答案，我已经能够进一步调试它。

析构函数在 Service.cc 中定义。如果我在头文件中给析构函数一个主体，一切都会正常工作。

现在析构函数“工作”了，我遇到了在 Service.cc 中定义的其他方法，但没有找到。

使用@ephemient 的方法，在我看来这些符号实际上已包含在库中。还是我错误地读取了输出？

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

我的 src/gdata/service/Makefile.am 看起来像这样：

我的 test/Makefile.am 看起来像这样：

gdatayoutube 工作得很好。它是使用来自客户端目录而不是服务（ gdata/client/libgdata_gdata_client.la ）的代码的旧代码......我看不出如何从服务设置客户端之间有任何区别。：-/

**编辑#2：##

好吧，我不知道这是怎么发生的，但我想我发现了我的问题。我认为测试应用程序链接的是我正在处理的库的已安装版本，而不是 src/ 中内置的本地版本。

我将对此进行更多探索，也许下次再问一些其他问题。

我有一个使用 autoconf / automake 的非常复杂的（C++）项目，其中包括一些“生成的”文件（foo.yy -> foo.cc）。实际构建是使用“控制脚本”（Gentoo .ebuild 对于那些熟悉该概念的人）在各种平台上完成的。

现在，其中一个目标平台不正确支持 foo.yy -> foo.cc 步骤，必须使用在 Linux 机器上生成的 foo.cc 文件。

现在我有两种方法可以解决这个问题：

1) 将 foo.cc 签入项目存储库，并以某种方式修补 configure.in（或其他）以包括对 foo.yy / foo.cc 的时间戳检查，如果在有问题的目标上运行时会生成一个可理解的错误消息，并且过时foo.cc;

2) 将 foo.cc 签入到控制脚本库中，并有脚本控制时间戳并给出错误消息。

我可以做 2) 没问题，但我认为这不是放置 foo.cc 的正确位置。

另一方面，我对 autoconf / automake 了解不多，也不知道如何在 configure.in （或任何地方）中实现时间戳检查 / 错误消息。

您有什么建议，这里有人知道如何解决解决方案 1）吗？

编辑：使用解决方案 3) 解决，调整有问题的目标框，直到它能够自己执行 foo.yy -> foo.cc 步骤。我的问题解决了。

但我会留下这个问题 - 如何使用 autoconf / automake 进行时间戳检查 / 可理解的错误消息？

我正在创建一个libgdata包含一些测试和未安装程序的库。我遇到的问题是，一旦我安装了库一次，程序似乎链接到已安装的版本，而不是本地版本../src/libgdata.la。

什么可能导致这种情况？我做错了什么可怕的事情吗？

这是我的test/Makefile.am样子：

（libapiutil是另一个库，它有一些帮助处理 libcurl 和 libxml++ 的东西）

因此，例如，如果我在没有安装任何东西的情况下运行测试，一切正常。我可以在本地进行更改，它们会立即被这些程序拾取。

如果我安装该软件包，这些程序将编译（看起来它实际上确实在本地查找标头），但是一旦我运行该程序，它就会抱怨缺少符号。

据我所知，它基于 make 输出链接到新建的库（../src/libgdata.la），所以我不确定为什么会发生这种情况。如果我删除已安装的文件，对 src/* 的本地更改会被很好地拾取。

我在下面包含了 gdatacalendar 的 make 输出。

帮助。:)

更新

addCommonRequestHeader()当我在安装没有该方法的库之后将方法添加到 Service 类时，当我尝试运行日历程序时收到以下消息addCommonRequestHeader()。

尤金尝试设置$LD_LIBRARY_PATH变量的建议没有帮助。

更新 2

我做了两个测试。首先，我在删除了我的 dev-install 目录（--prefix）之后这样做了，在这种情况下，它会创建test/.libs/lt-gdatacalendar. 但是，一旦我安装了库，它就会创建test/.libs/gdatacalendar。ldd 的输出对于两者都是相同的，但有一个例外：

什么会导致在一种情况下创建 lt-gdatacalendar 而在另一种情况下创建 gdatacalendar？

ldd 在 libgdata 上的输出是：

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

我有我想在所有 unix 系统上编译的代码，但是如果 -m64 我可用并且它可以工作，我希望配置脚本使用它。如何让 autoconf 检查 -m64 是否有效，如果有效，请使用它？