带有 `*.in` 扩展名的源文件

Question

在查看某些源代码树时，有时我会遇到扩展名为“*.in”的文件，通常是属于 /etc 或 /usr/share 下某处的未编译文件。

例如，在openwsman源代码中，我可以看到文件：

etc/owsmangencert.sh.in

按内容对应

/etc/openwsman/owsmangencert.sh

从 RPM (RHEL7) 部署时，保存一些变量引用。

我假设在构建过程中使用这样的文件最终出现在提到的路径中。但为什么他们被命名originalname.in而不是originalname？像这样的文件在登陆之前通常会发生什么？

这些文件是如何命名的？有人能指出我正确的文件吗？

注意 Openwsman 也有 etc/owsmangencert.sh.cmake，情况类似。

Answer 1

据我所知，没有一个程序旨在使用.in 文件，但使用后缀.in确实暗示了它不是最终文件的事实。相反，该.in文件将作为一种模板或输入来生成具有相同名称但没有.in后缀的文件。

在 openwsman 的情况下，您经常会在可以从源代码编译的包中找到的一个示例是configure.in文件。这由 autoconf/automake 处理并生成一个名为configure. 这个新版本是一个实际的 shell 脚本，您可以在命令行上执行它。

反过来，configure脚本本身也可以处理某些.in文件。以名为openwsman.pc.in. 在那里，你会看到像

Version: @VERSION@

@符号之间的东西是配置脚本使用的变量。在生成的 openwsman.pc.in` 中，将填充该变量的值，例如：

Version: 2.4.5

@(variablename)@CMake 构建系统也识别此语法。所以运行 CMake 也会将openwsman.pc.in文件转换为openwsman.pc. 它这样做是因为CMakeLists.txt文件中的以下行：

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/openwsman.pc.in ${CMAKE_CURRENT_BINARY_DIR}/openwsman.pc)

该etc/owsmangencert.sh.cmake转换以同样的方式，但基于扩展我会假设只有CMake的构建系统做到这一点，而不是配置脚本。在这种情况下，在etc/CMakeLists.txt文件中找到相关行：

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/owsmangencert.sh.cmake ${CMAKE_CURRENT_BINARY_DIR}/owsmangencert.sh)

所以总而言之，没有一份文档可以解释这一点，但它经常用于构建脚本，如配置脚本或来自 CMake 的 CMakeLists.txt 文件。