Question

简单地说，我在我们正在开发的项目中运行了一个“buildconf.py.am.in”文件。不是autotools的专家（我不得不为这份工作学习它们），这对我来说似乎很奇怪。里面有两个VAR=@VAR@和两个VAR=[@]VAR[@]。

怎么会有“.am.in”？对我来说，这意味着我们编写一个.in来生成一个.am，它将用于生成另一个.in（或.py，也许）。它看起来“合法”还是应该“固定”？因此，在configure步骤之后，我确实有一个“buildconf.py.am”，它在make进程中用于生成.py。它包含以下内容：

do_subst = sed  -e 's,\[@\]APP_VARDIR\[@\],$(localstatedir)/app/,g' \
    -e 's,\[@\]APP_LOGDIR\[@\],$(logdir),g'

buildconf.py: buildconf.py.am
    $(do_subst) < $(srcdir)/buildconf.py.am > buildconf.py

这是“正常”还是“可接受”？因为我正在努力巩固整个事情，因为一切都变得“棘手”而且难以更新，看起来它对我来说是大量修复之一。

TY！

编辑：

该脚本主要定义“插件”使用的文件夹的路径，因此需要诸如datadir或soft installdir之类的东西。它还定义了这些插件使用的文件夹结构，以便可以通过所谓的插件的python代码导入它们。此外，这些“插件”实际上是应用程序的服务器/路由层。

buildconf.py.am.in文件未生成，但是手写;
buildconf.py.am在其他AC_CONFIG_FILES中声明（怎么可能？它应该告诉“旁边必须有buildconf.py.am.in.am，它将用于生成{ {1}}然后创建一个“buildconf.py.am.in.in文件......但我们想要的只是buildoncf.py.am.in};
运行buildconf.py生成configure，设置的变量是两个布尔值，它告诉我们是否提供了mongoDB和web UI插件;
buildconf.py.am生成最终make，在需要保留常量的地方导入。这是在这个时候完成的，因为它需要-I guess-在配置步骤中扩展变量。

Answer 1

我认为这可能只是一个命名问题。

通常 .am文件包含在Makefile.am中，并由automake扩展，因此例如它们用于根据目录定义源和目标，同时保持整体构建不递归。

你可以包含Makefile级别的文件，以便make执行包含，但调用它们.am听起来是错误的。< / p>

但是在这种情况下，它们都不是，这可能应该被称为.in.in（有一些脚本可以做类似的事情），但感觉有点过头了。通过在make阶段应用所有替换，它可能只需要进行一次处理。

我想最有可能的情况是，原始扩展不正确并且分层，但不知道代码库很难说。

“.am.in”？在没有生成的情况下写“.in”是否可以？

1 个答案: