AC_SUBST 指定额外的源目录

Posted 2023-02-22

【中文标题】AC_SUBST 指定额外的源目录

【英文标题】：AC_SUBST to specify additional source dir

【发布时间】：2019-09-23 02:23:21

【问题描述】：

我有一个将变量定义为的配置：

AC_ARG_WITH(mylib,
[  --with-mylib=PATH     Sets PATH for my additional sources (../mylib) ],
[
        MYLIB_PATH="$withval"
        AC_MSG_RESULT(Using mylib source from $withval)
],[
        MYLIB_PATH="../mylib"
])

dnl convert to absolute path
MYLIB_PATH=`readlink -f $MYLIB_PATH`
AC_SUBST(MYLIB_PATH)
AC_OUTPUT(Makefile src/Makefile)

我的***Makefile.am是：

ACLOCAL_AMFLAGS = -I m4
SUBDIRS = src

然后在我的src/Makefile.am我想从指定的mylib路径添加源：

...
bin_PROGRAMS = fooApp
fooApp_SOURCES = main.c \
            @MYLIB_PATH@/logger.c
fooApp_CFLAGS = -I@MYLIB_PATH@/lib

所以我的想法是为这些共享资源保留一个单独的存储库。在配置期间，我可以指定我在哪里结帐。即：

./configure --with-mylib=/tmp/mylib 

不幸的是，当我运行 configure 时，该脚本似乎在我的 src 下创建了一个 .deps（用于 .Po 文件），就像它剥离了路径的第一个斜杠一样：

src/tmp/mylib/.deps/fooApp-logger.Po

现在，显然 make 失败了，因为它尝试从以下路径加载 .Po 文件：/tmp/mylib/.deps/fooApp-logger.Po

知道我做错了什么吗？告诉 configure 在哪里可以找到我的其他来源的正确方法是什么？

【问题讨论】：

我不确定您为什么会看到您所看到的特定行为，但您的做法非常不合常规。如果您有想要在多个项目中使用的代码而不将其复制到每个项目中，那么标准的做法是构建一个包含它的库，然后将该库链接到您的其他项目。如果您愿意，可以将其设为静态库。这对您来说将是一条更顺畅的道路。

嗨 John，嗯，是的，库绝对是一种可行的方法，但是我的项目针对一些嵌入式系统，在这些系统中，首先将文件分组到一个库中，然后只在一个库中使用该库没有什么意义应用程序。我知道这是一条很好的路线，它可以接受解释（以及不同的编码实践）。我对 AC_SUBST 的问题很奇怪。似乎如果我为 MYLIB_PATH 使用相对路径，一切都会按预期工作（.deps 目录是在正确的目录中创建的），但如果 MYLIB_PATH 是绝对路径，则它不起作用。

实际上，我刚刚测试过，如果我将 MYLIB_PATH 规范化为相对路径而不是绝对路径，我的情况就可以完美运行。我想知道这是否是某些 autoconf 宏的错误...将进行更多调查并在此处发布解决方案。

如果您正在为任何给定的目标平台构建有问题的源以仅在一个应用程序中使用，那么您最好的做法可能是将其复制到该应用程序自己的源中。这样做的好处是您始终知道应用程序中的源代码版本。您所描述的内容似乎是为了您自己在执行构建时的方便而设计的，这是一个很好的目标，但在这种特殊情况下，它会带来足够大的可维护性成本，我不推荐它。

【参考方案1】：

好吧，对于遇到类似问题的人来说，我怀疑是 automake 的问题，它在通过 AC_SUBST 从扩展路径计算 .Po 文件的路径位置时做错了。

解决方法是在定义通过 AC_SUBST 扩展的路径时始终使用相对路径而不是绝对路径。

在上面的例子中，不要使用readlink`` to convert MYLIB_PATH to absolute, instead userealpath```来查找执行构建的目录的相对路径：

MYLIB_PATH=`realpath --relative-to src "$MYLIB_PATH"`

我创建了一个完整的复制器并向 GNU 提交了一个错误 (bug#37499)