问".am.in“？写".in“而不生成它可以吗？

EN

简单地说，我在我们正在开发的项目中运行了一个"buildconf.py.am.in“文件。并不是很擅长自动工具(我不得不为这份工作学习它们)，这对我来说是相当奇怪的。里面有两个VAR=@VAR@和两个VAR=[@]VAR[@]。

怎么会有".am.in“呢？对我来说，这意味着我们编写一个.in来生成一个.am，该.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

这是“正常”还是“可接受”？当我试图整合整件事情的时候，因为一切都变得“棘手”，而且很难更新，这似乎是我的大量修复之一。

泰！

编辑：

这个脚本主要为"plugins“使用的文件夹定义路径，因此需要一些东西，比如datadir或软安装。它还定义了这些插件要使用的文件夹结构，这样就可以通过所谓插件的python代码导入它们。此外，这些“插件”实际上是应用程序的服务器/路由层。

• buildconf.py.am.in文件不是生成的，而是手工编写的；
• buildconf.py.am是在AC_CONFIG_FILES中声明的(怎么可能呢？)它应该告诉“必须有一个buildconf.py.am.in.am在它旁边，它将用于生成一个buildconf.py.am.in.in然后生成一个"buildoncf.py.am.in文件.但我们想要得到的只是buildconf.py)；
• 运行configure会生成buildconf.py.am，设置的变量是两个布尔值，用于判断是否提供了mongoDB和web插件；
• make生成最终的buildconf.py，将在需要它持有的常量的地方导入。这是在此时完成的，因为它需要在配置步骤中扩展-I猜测变量。