Até onde eu sei, não há um único programa que se destine a usar .in
arquivos, mas usando o sufixo .in
não indica o fato de que não é o
arquivo final. Em vez disso, o arquivo .in
servirá como um tipo de modelo ou entrada
para gerar o arquivo com o mesmo nome, mas sem o sufixo .in
.
No caso de openwsman, um exemplo você encontrará em pacotes que
você pode compilar a partir da fonte, é o arquivo configure.in
. Isso é processado
por autoconf / automake e resulta em um arquivo chamado configure
. Este novo
version é um script de shell real que você pode executar na linha de comando.
Por sua vez, o próprio script configure
também pode processar determinados arquivos .in
.
Por exemplo, pegue o arquivo chamado openwsman.pc.in
. Lá você verá
linhas como
Version: @VERSION@
A coisa entre os símbolos @
é uma variável usada pelo configure
roteiro. No openwsman.pc.in resultante, o valor dessa variável
será preenchido, por exemplo:
Version: 2.4.5
Essa sintaxe @(variablename)@
também é reconhecida pelo sistema de criação do CMake.
Portanto, a execução do CMake também transformará o arquivo openwsman.pc.in
em openwsman.pc
.
Ele faz isso por causa da seguinte linha no arquivo CMakeLists.txt
:
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/openwsman.pc.in ${CMAKE_CURRENT_BINARY_DIR}/openwsman.pc)
O etc/owsmangencert.sh.cmake
é transformado da mesma maneira, mas baseado
na extensão eu diria que apenas o sistema de compilação CMake faz isso
e não o script de configuração. Neste caso, a linha relevante é encontrada em
o arquivo etc/CMakeLists.txt
:
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/owsmangencert.sh.cmake ${CMAKE_CURRENT_BINARY_DIR}/owsmangencert.sh)
Então, em conclusão, não há uma única documentação que explique isso, mas é frequentemente usado em scripts de construção como configurar scripts ou arquivos CMakeLists.txt de CMake.