Automake e autoconf são a maneira padrão de compilar código?

22

Às vezes, compilo aplicativos da fonte e já uso:

./configure
make
sudo make install

Mas, recentemente, me deparei com o ./autogen.shque gera o configure e cria scripts para mim e os executa.

Quais outros métodos para otimizar a compilação C / C ++ / C # (mono) existem? Make parece um pouco velho. Existem novas ferramentas por aí? Dada a escolha, qual devo usar?

Louis Salin
fonte
não há nada como apenas 'código'. Por exemplo, se você obtiver o código Java, provavelmente o construirá usando maven ou ant, se você obtiver o Python, uma boa opção é setuptools. Não há maneiras padrão de compilar nada. Talvez você deva reformular a pergunta.
Diego 10/08
Bom ponto. Na verdade, estou codificando em C # com mono, mas minha pergunta também se aplica ao C / C ++.
Louis Salin
Nota pequena: autogen.sh não executa make for you, apenas configure.
Sandy
@ Sandy autogen.shsão principalmente scripts personalizados, que normalmente invocam, autoreconfmas também podem invocar ./configuree até make. Não acho que seu comportamento seja padronizado de forma alguma; o objetivo principal é ter um arquivo exetable dentro do projeto, que as pessoas podem correr (em vez de ter que saber que eles precisam para conjurar autoreconf)
trema

Respostas:

42

Autoconf e Automake foram criados para resolver um problema evolutivo do Unix.

À medida que o Unix evoluiu para direções diferentes, os desenvolvedores que queriam código portátil tenderam a escrever código como este:

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

Como o Unix foi introduzido em diferentes implementações (BSD, SystemV, muitos garfos de fornecedores e, mais tarde, Linux e outros sistemas similares ao Unix), tornou-se importante para os desenvolvedores que desejavam escrever código portátil para escrever código que não dependia de uma marca específica do sistema operacional. , mas nos recursos expostos pelo sistema operacional. Isso é importante porque uma versão Unix introduziria um novo recurso, por exemplo, a chamada do sistema "send", e mais tarde outros sistemas operacionais a adotariam. Em vez de ter um espaguete de código que verifica marcas e versões, os desenvolvedores começaram a pesquisar por recursos, então o código se tornou:

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

A maioria dos arquivos LEIA-ME para compilar o código-fonte nos anos 90 apontou os desenvolvedores para editar um arquivo config.h e comentar os recursos adequados disponíveis no sistema, ou enviaria arquivos config.h padrão para cada configuração do sistema operacional testada.

Esse processo foi complicado e propenso a erros e foi assim que o Autoconf surgiu. Você deve pensar no Autoconf como uma linguagem composta de comandos do shell com macros especiais que foram capazes de substituir o processo de edição humana do config.h por uma ferramenta que investigava a funcionalidade do sistema operacional.

Você normalmente escreveria seu código de análise no arquivo configure.ac e, em seguida, executaria o comando autoconf que compilaria esse arquivo no comando executável configure que você viu usado.

Portanto, quando você executa, ./configure && makevocê está pesquisando os recursos disponíveis em seu sistema e construindo o executável com a configuração que foi detectada.

Quando os projetos de código aberto começaram a usar sistemas de controle de código-fonte, fazia sentido fazer check-in no arquivo configure.ac, mas não o resultado da compilação (configure). O autogen.sh é apenas um pequeno script que chama o compilador autoconf com os argumentos de comando corretos para você.

-

A Automake também cresceu a partir das práticas existentes na comunidade. O projeto GNU padronizou um conjunto regular de metas para Makefiles:

  • make all construiria o projeto
  • make clean removeria todos os arquivos compilados do projeto
  • make install instalaria o software
  • coisas como make diste make distcheckprepararia a fonte para distribuição e verificaria se o resultado era um pacote completo de código-fonte
  • e assim por diante...

A criação de makefiles compatíveis tornou-se onerosa porque havia muitos clichês repetidos várias vezes. Então o Automake foi um novo compilador que se integrou ao autoconf e processou o Makefile de "origem" (chamado Makefile.am) em Makefiles que poderiam então ser alimentados ao Autoconf.

A cadeia de ferramentas automake / autoconf realmente usa várias outras ferramentas auxiliares e elas são aumentadas por outros componentes para outras tarefas específicas. À medida que aumentava a complexidade da execução desses comandos, nasceu a necessidade de um script pronto para execução, e é daí que veio o autogen.sh.

Até onde eu sei, o Gnome foi um projeto que introduziu o uso desse script auxiliar autogen.sh

miguel.de.icaza
fonte
Apenas um pequeno detalhe: os padrões GNU exigem o envio de arquivos gerados em tarballs, para reduzir as dependências de compilação a um mínimo de ferramentas universalmente disponíveis. Se você obtiver uma fonte bruta (de um sistema de controle de versão, por exemplo), os arquivos gerados não estarão lá.
vonbrand
14

Existem dois "grandes jogadores" nesta área; Cmake e GNU Autotools.

  • O GNU Autotools é a maneira GNU de fazer as coisas e está bastante focado no * nix. É uma espécie de sistema de meta-construção, fornecendo um conjunto de ferramentas que geram configurações específicas e criam arquivos para o que você está tentando fazer. Isso ajuda você a fazer mais alterações em seu código sem precisar manipular diretamente seu sistema de compilação, além de ajudar outras pessoas a criar seu código de maneiras que você não havia projetado para - sob * nix.

  • Cmake é a maneira multiplataforma de fazer as coisas. A equipe da Cmake cria software de várias maneiras diferentes, com GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux, qualquer que seja. Se você está preocupado com a portabilidade de sua base de código, este é o caminho a seguir.

Como já foi mencionado, algumas pessoas parecem gostar de Scons. Se você conhece o Python, isso pode fornecer mais consistência no seu ambiente de trabalho.

O Ruby também tem um tipo de sistema de meta-construção chamado Rake, que é bem legal por si só e é muito útil para aqueles que já estão familiarizados com o Ruby.

Eli Frey
fonte
6

Scons é uma possível substituição, embora eu não tenha experiência pessoal. Também é implementado no Python, o que pode ser um problema, dependendo do ambiente de construção.

tsvallender
fonte
2
Portabilidade não é o problema, já que o Python agora está praticamente em todo lugar. A principal reclamação sobre SCons até agora é que é inaceitavelmente lenta. Existem alguns ajustes para sacrificar a precisão da construção em favor da velocidade, mas não tenho certeza se ainda está em pé de igualdade com o Make.
Alex B
3

Se você estiver usando C # / Mono, poderá usar o msbuild (os arquivos .sln / .csproj usados ​​pelo MonoDevelop e Visual Studio) para gerenciar todo o processo de compilação.

Você pode criar a partir do MonoDevelop ou executar o xbuildcomando no seu terminal favorito (funciona melhor em Mono> = 2.6). Isso é extremamente fácil e requer praticamente nenhum trabalho de sua parte, porque o MonoDevelop manipulará os arquivos msbuild para você, e você não precisará editá-los, a menos que queira ajustar coisas além do que a interface do usuário do MonoDevelop pode fazer por você.

Não estou familiarizado com o modo como as pessoas que dependem do msbuild lidam com as instalações de seus projetos, mas você sempre pode perguntar isso. ;-)

Sandy
fonte
Sim, eu sei sobre o xbuild, mas estou tentando me afastar dos IDEs que só querem segurar minha mão. Além disso, o Mono é compilado usando o Mono e usa o autoconf, então eu queria saber um pouco mais. Obrigado!
Louis Salin
1
Curiosamente, muitos projetos Mono estão tentando migrar para o msbuild agora que o xbuild está funcionando tão bem. Isso facilita um pouco o suporte ao Windows / Mac. O Mono tem tanto código C que não sei ao certo como seria prático mudar para o xbuild. Mas o autoconf funciona muito bem, assim como o que funciona para você. :-)
Sandy
0

Para C #, você pode usar o xbuild (e o msbuild no windows), que criará o projeto a partir dos arquivos do projeto.


fonte