É automake e autoconf a maneira padrão de compilar o código?

Question

Às vezes, eu compilo aplicativos do código-fonte e estou usando:

./configure
make
sudo make install

Mas recentemente, deparei com ./autogen.sh , que gera e configura scripts para mim e os executa.

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

    

Answer 1

Autoconf e Automake foram definidos para resolver um problema evolucionário do Unix.

Como o Unix evoluiu para diferentes direções, 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 bifurcado em diferentes implementações (BSD, SystemV, muitos forks de fornecedores e posteriormente Linux e outros sistemas semelhantes a Unix), tornou-se importante para desenvolvedores que quisessem escrever código portátil para escrever código que não dependesse de uma marca em particular. do sistema operacional, mas em recursos expostos pelo sistema operacional. Isso é importante porque uma versão Unix introduziria um novo recurso, por exemplo, a chamada de sistema "send" e, posteriormente, outros sistemas operacionais a adotariam. Em vez de ter um espaguete de código que verificava marcas e versões, os desenvolvedores começaram a investigar por recursos, então o código se tornou:

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

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

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

Você normalmente escreveria seu código de sondagem no arquivo configure.ac e depois executaria o comando autoconf que compilaria este arquivo para o comando de configuração executável que você viu usado.

Portanto, quando você executar ./configure && make , estará investigando os recursos disponíveis em seu sistema e, em seguida, criando o executável com a configuração que foi detectada.

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

-

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

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

Construir makefiles complacentes tornou-se pesado porque havia muito clichê que era repetido várias vezes. Então, o Automake era um novo compilador que se integrava ao autoconf e processava o "source" do Makefile (chamado Makefile.am) em Makefiles que poderiam então ser alimentados no Autoconf.

O toolchain automake / autoconf na verdade usa várias outras ferramentas auxiliares e elas são aumentadas por outros componentes para outras tarefas específicas. À medida que crescia a complexidade de executar esses comandos em ordem, nasceu a necessidade de um script pronto para execução, e é de onde veio o autogen.sh.

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

    

Answer 2

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

• O GNU Autotools é a maneira GNU de fazer as coisas, e é bastante focado em * nix. É uma espécie de sistema de meta-compilaçã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 ter que manipular diretamente seu sistema de compilação e ajuda os outros a criar seu código de maneiras que você não tinha projetado - em * nix.

• O Cmake é a maneira multiplataforma de fazer as coisas. A equipe da Cmake constrói software de muitas maneiras diferentes, com o GCC, o Visual Studio, o XCode, o Windows, o OSX, o Solaris, o BSD, o GNU / Linux. 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ê estiver familiarizado com o Python, isso pode fornecer mais consistência em seu ambiente de trabalho.

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

    

Answer 3

Scons é um possível substituto, embora eu não tenha experiência pessoal. Ele também é implementado em Python, o que pode ser um problema, dependendo do ambiente de criação.

    

Answer 4

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

Você pode criar o MonoDevelop ou executar o comando xbuild no seu terminal favorito (funciona melhor em Mono > = 2.6). Isso é extremamente fácil e não 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 deseje ajustar as coisas além do que a interface do MonoDevelop pode fazer por você.

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

    

Answer 5

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