Arquivos de origem com extensão '* .in'

Question

Ao procurar em algumas árvores de código-fonte, às vezes eu encontro arquivos com extensão "* .in", normalmente para arquivos não compilados que pertencem a algum lugar em / etc ou / usr / share.

Por exemplo, no código-fonte openwsman , posso ver o arquivo:

etc/owsmangencert.sh.in

qual por conteúdo corresponde a

/etc/openwsman/owsmangencert.sh

quando implantado a partir do RPM (RHEL7), salve para algumas referências de variáveis.

Assumo que arquivos como este são usados no processo de construção para finalmente aparecer no caminho mencionado. Mas por que eles são nomeados originalname.in em vez de originalname ? O que geralmente acontece com arquivos como este antes deles pousarem?

Como esses arquivos são chamados? Alguém pode me indicar os documentos certos?

Note que o Openwsman também possui o etc / owsmangencert.sh.cmake, que é um caso similar.

    

Answer 1

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.

    

Answer 2

Existem arquivos que são modelos, veja dentro owsmangencert.sh.in

CERTFILE=@SYSCONFDIR@/servercert.pem
KEYFILE=@SYSCONFDIR@/serverkey.pem
CNFFILE=@SYSCONFDIR@/ssleay.cnf

@SYSCONFDIR @ será substituído caminho real

Após a configuração do automake, será gerado o config.status, que substituirá os tokens pelos valores reais, durante o processo make. Então isso automatiza os modelos. Para conhecimento mais profundo .

    

Answer 3

os únicos arquivos * .in que eu deparei são o config.in para especificar passos .configure com autoconf e automake.

Neste sentido, o * .in é um arquivo de variáveis. Ele mantém seu script limpo de variáveis, para que você possa editar o acesso a um arquivo de variáveis e executar o acesso no script, mas não editar o acesso no script.