在 autotool 中包含不同 bin_Programs 的不同库答案

【问题标题】：Including different libraries for different bin_Programs in autotool在 autotool 中包含不同 bin_Programs 的不同库
【发布时间】：2020-01-21 12:26:37
【问题描述】：

我们正在使用 Autotools 构建我们的 c++ 应用程序。我们正在 Makefile.am 中创建两个 bin_Programs，如下所示：

bin_PROGRAMS = \ applications/A/a \ applications/B/b

目前，我们在这两个程序中都包含相同的库，如下所示：

INCLUDES = -I@NE_ROOT@ -I@CORE_ROOT@/include @MYLIB_CFLAGS@ @BOOST_CFLAGS@ @LOG4CPP_CFLAGS@

这是@MYLIB_CFLAGS@的定义：

MYLIB_CFLAGS=-I${mylib_include_dir}

Makefile.am 中的变量为空如下：

applications_A_a_SOURCES = 

applications_A_a_LDADD =

applications_A_a_LDFLAGS =

我们正在为 b 程序定义相同的变量。

我注意到 b 程序在 include 中不需要 @MYLIB_CFLAGS@，并且在尝试更新 Glibc 时这会导致问题。我的问题是，是否有办法将 @MYLIB_CFLAGS@ 包含在“a”应用程序中，但不包含在“b”应用程序中。 `

【问题讨论】：

标签： c++ makefile build autotools autoconf

【解决方案1】：

目前，我们为这两个库包含相同的库程序如下：
INCLUDES = -I@NE_ROOT@ -I@CORE_ROOT@/include @MYLIB_CFLAGS@ @BOOST_CFLAGS@ @LOG4CPP_CFLAGS@

明确术语对您有利，因为这样可以更轻松地与其他人就此类问题进行交流并解释文档，例如the Automake manual。为此，INCLUDES 变量的目的是保存编译器标志，这些标志指示应该出现在 C 和 C++ #include 指令的搜索路径中的位置，或者为其他语言的编译器提供类似目的.它只是间接地与库有关，当按预期使用时，它肯定不会导致任何地方包含任何内容。

此外，更直接地与您的问题相关，这使得 INCLUDES 变量成为各种 *_CPPFLAGS 变量的附属物，这些变量更普遍地用于传达旨在调节预处理器行为的标志。这与旨在调整编译器行为的标志不同，*_CFLAGS (C)、*_CXXFLAGS (C++) 和其他一些标志被指定。人们通常可以避免使用错误的变量来传达标志，但这确实会有所作为。当然，对于特定于项目的变量，不需要遵守这些命名约定，但我更愿意这样做以保持清晰。

因此，考虑到 ...

这是@MYLIB_CFLAGS@的定义：
MYLIB_CFLAGS=-I${mylib_include_dir}

...该变量传递的唯一标志是-I 标志，因此如果我进行命名，该变量将是MYLIB_CPPFLAGS。但这是一个特定于项目的变量，所以它的名字的意义在于你决定它是什么。

Makefile.am 中的变量为空如下：

这不是很有用，我怀疑它实际上误导了你。没有必要为 Automake 指定空变量。这样做对 Automake 的意义与完全省略变量没有什么不同，但我怀疑它可能给您的印象是，Makefile.am 中给出的那些是唯一可用的每个目标变量。他们不是。事实上，还有更多，如in the manual所列。

特别是，有（名义上）变量applications_A_a_CPPFLAGS 和applications_B_b_CPPFLAGS，您可以在其中列出特定于一个目标或另一个目标的预处理器标志。这些是全局效应变量（例如INCLUDES）的累积值，因此解决上述问题的一种方法是更改INCLUDES 并添加applications_A_a_CPPFLAGS，如下所示：

INCLUDES = -I@NE_ROOT@ -I@CORE_ROOT@/include @BOOST_CFLAGS@ @LOG4CPP_CFLAGS@

applications_A_a_CPPFLAGS = @MYLIB_CFLAGS@

现在@MYLIB_CFLAGS@ 中的标志将仅用于构建applications_A_a。

我还注意到，您说所有Makefile.am 文件中列出的特定于目标的变量都是空的，这很可疑。这不一定是错误的，但请注意，不是仅标头的库也需要以某种方式在链接器变量中表示。也许您有一个 LDADD 变量，通过该变量为所有目标指定相同的库（或者您使用 AM_LDFLAGS 执行此操作，这在某些情况下可能有效但不正确，或者您使用 LDFLAGS，这将更糟）。如果您需要这样做，那么指定特定于一个程序目标或另一个程序目标的二进制库的正确方法是通过变量applications_A_a_LDADD 和applications_B_b_LDADD。

【讨论】：

谢谢我的回答。你对 LDADD 是对的，我错过了一些库被添加到应用程序 LDADD 之一，但不是 mylib。实际上 Mylib 是一个有两个头文件的共享对象。我没有看到我们将 .so 文件添加到 LDADD 的任何地方，但是在 make 期间更新 GLibc 时，我收到警告，交叉编译器中使用的 STDC++ 与 mylib.so 中使用的 stdc++ 冲突。因此，我认为 include 包括库。