在查看某些源代码树时,有时我会遇到扩展名为“*.in”的文件,通常是属于 /etc 或 /usr/share 下某处的未编译文件。
例如,在开放式网络管理员源代码,我可以看到文件:
etc/owsmangencert.sh.in
其内容对应于
/etc/openwsman/owsmangencert.sh
从 RPM (RHEL7) 部署时,保存一些变量引用。
我假设这样的文件在构建过程中使用,最终出现在提到的路径中。但为什么他们的名字originalname.in
不是这样的呢originalname
?此类文件在落地之前通常会发生什么?
此类文件如何命名?有人能指出我正确的文件吗?
请注意,Openwsman 也有 etc/owsmangencert.sh.cmake,这是类似的情况。
答案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 文件。
答案2
有文件有模板,看里面owsmangencert.sh.in
CERTFILE=@SYSCONFDIR@/servercert.pem
KEYFILE=@SYSCONFDIR@/serverkey.pem
CNFFILE=@SYSCONFDIR@/ssleay.cnf
@SYSCONFDIR@将替换实际路径
automake配置后,将生成config.status,在make过程中它将用实际值替换令牌。这就是 automake 模板。为了更深知识。
答案3
我遇到的唯一 *.in 文件是 config.in,用于使用 autoconf 和 automake 指定 .configure 步骤。
从这个意义上说,*.in 是一个变量文件。它使您的脚本保持干净的变量,因此您可以拥有对变量文件的编辑访问权限和对脚本的运行访问权限,但不能对脚本进行编辑访问权限。