Quais são as diferenças entre Autotools, Cmake e Scons?


259

Quais são as diferenças entre Autotools, Cmake e Scons?


Este tópico já foi discutido no wiki do Scons . Sugiro que você visite os seguintes links: 1. scons.org/wiki/SconsVsOtherBuildTools Você visitou um tópico de discussão muito semelhante no Fórum Ubuntu ?
#

Você pode verificar este pdf www-alt.gsi.de/documents/DOC-2007-Sep-17-1.pdf ; possui prós e contras e também alguns detalhes sobre cada ferramenta.
Adam

Respostas:


190

Na verdade, a única "verdadeira graça salvadora" do Autotools é que é o que todos os projetos GNU estão usando amplamente.

Problemas com as ferramentas automáticas:

  • Sintaxe de macro verdadeiramente do ARCANE m4 combinada com scripts de shell distorcidos detalhados para testes de "compatibilidade" etc.
  • Se você não está prestando atenção, você vai estragar capacidade cross-compilação (Deve ser claramente observado que a Nokia surgiu com Scratchbox / Scratchbox2 para o lado-passo altamente quebrado configurações de compilação Autotools para Maemo / Meego.) Se, por qualquer Por isso, você tem caminhos fixos e estáticos em seus testes. Você interromperá o suporte à compilação cruzada, porque não respeitará a especificação do sysroot e extrairá coisas do sistema host. Se você interromper o suporte à compilação cruzada, ele tornará seu código inutilizável para coisas como o OpenEmbedded e o tornará "divertido" para distribuições que tentam criar seus lançamentos em um compilador cruzado em vez de no destino.
  • Faz uma quantidade enorme de testes para problemas com compiladores antigos e quebrados que o NOBODY atualmente usa com praticamente qualquer coisa de produção atualmente. A menos que você esteja criando algo como glibc, libstdc ++ ou GCC em uma versão verdadeiramente antiga do Solaris, AIX ou algo semelhante, os testes são uma perda de tempo e são uma fonte de muitas e possíveis quebras de coisas como as mencionadas acima.
  • É uma experiência bastante dolorosa obter uma configuração do Autotools para criar código utilizável para um sistema Windows. (Embora eu tenha pouco uso do Windows, é uma preocupação séria se você estiver desenvolvendo um código supostamente multiplataforma.)
  • Quando ele quebrar, você passará HOURS perseguindo seu rabo tentando resolver as coisas que quem escreveu os scripts errou para resolver sua compilação (na verdade, é isso que estou tentando fazer (ou melhor, rasgue completamente as ferramentas automáticas - duvido que haja tempo suficiente no restante deste mês para resolver a bagunça ...) para o trabalho no momento em que estou digitando isso.O Apache Thrift possui um daqueles sistemas de construção BROKEN que não se cruzam -compilar.)
  • Na verdade, os usuários "normais" NÃO farão apenas "./configure; make" - por muitas coisas, eles estarão puxando um pacote fornecido por alguém, como fora de um PPA ou seu fornecedor de distribuição. Usuários "normais" não são desenvolvedores e não estão pegando tarballs em muitos casos. Isso é esnobismo da parte de todos por presumir que esse será o caso. Os usuários típicos de tarballs são desenvolvedores fazendo as coisas, então eles serão atingidos com o quebrantamento, se houver.

Funciona ... na maioria das vezes ... é tudo o que você pode dizer sobre o Autotools. É um sistema que resolve vários problemas que realmente dizem respeito apenas ao projeto GNU ... para o código básico da cadeia de ferramentas. (Edit (24/05/2014): Note-se que esse tipo de preocupação é uma coisa potencialmente MAU de se preocupar. Heartbleed surgiu parcialmente desse pensamento e, com sistemas modernos e corretos, você realmentenão tem negócios lidando com muito do que o Autotools corrige. O GNU provavelmente precisa fazer uma remoção de fragmentos da base de código, à luz do que aconteceu com o Heartbleed. a cadeia de ferramentas GNU está claramente funcionando corretamente. A afirmação de que "se integra perfeitamente ao Linux" é bastante ousada e incorreta . Ele se integra razoavelmente bem ao conjunto de ferramentas GNU e resolve os problemas que a TI tem com seus objetivos.

Isso não quer dizer que não haja problemas com as outras opções discutidas no tópico aqui.

SCons é mais um substituto para Make / GMake / etc. e parece muito bom, todas as coisas consideradas No entanto ...

  • Ainda é realmente mais uma ferramenta única do POSIX. Você provavelmente poderia obter mais facilmente o MinGW para criar coisas do Windows com isso do que com o Autotools, mas ainda é realmente mais voltado para as coisas do POSIX e você precisará instalar o Python e o SCons para usá-las.
  • Há problemas na compilação cruzada, a menos que você esteja usando algo como o Scratchbox2.
  • É verdade que é mais lento e menos estável que o CMake a partir de sua própria comparação. Eles vêm com um meio-coração (o lado POSIX precisa criar / gmake para construir ...) negativos para o CMake em comparação com os SCons. (Como um aparte, se você está precisando QUE muito extensibilidade sobre outras soluções, você deve estar se perguntando se o seu projeto é muito complicado ...)

Os exemplos dados para o CMake neste tópico são um pouco falsos.

Contudo...

  • Você precisará aprender um novo idioma.
  • Existem coisas contra-intuitivas se você estiver acostumado a Make, SCons ou Autotools.
  • Você precisará instalar o CMake no sistema para o qual está construindo.
  • Você precisará de um compilador C ++ sólido se não tiver binários pré-criados para ele.

Na verdade, seus objetivos devem ditar o que você escolhe aqui.

  • Você precisa lidar com um monte de toolchains quebradas para produzir um binário de trabalho válido? Se sim, você pode considerar o Autotools, ciente das desvantagens que mencionei acima. O CMake pode lidar com muito disso, mas se preocupa menos com isso do que o Autotools. Os SCons podem ser estendidos para se preocupar com isso, mas não é uma resposta imediata.
  • Você precisa se preocupar com os destinos do Windows? Nesse caso, o Autotools deve estar literalmente fora de operação. Nesse caso, os SCons podem / não ser uma boa escolha. Nesse caso, o CMake é uma escolha sólida.
  • Você precisa se preocupar com a compilação cruzada (aplicativos / bibliotecas universais, coisas como Google Protobufs, Apache Thrift, etc. DEVE se preocupar com isso ...)? Nesse caso, o Autotools podetrabalhe para você desde que não precise se preocupar com o Windows, mas você gastará muito tempo mantendo seu sistema de configuração à medida que as coisas mudam. No momento, o SCons é praticamente impossível, a menos que você esteja usando o Scratchbox2 - ele realmente não tem controle na compilação cruzada e você precisará usar essa extensibilidade e mantê-la da mesma maneira que você fará com a Automake. Nesse caso, convém considerar o CMake, pois ele oferece suporte à compilação cruzada sem tantas preocupações com vazamento da sandbox e funcionará com / sem algo como o Scratchbox2 e se integra perfeitamente a coisas como o OpenEmbedded.

Há uma razão para muitos projetos estarem abandonando o qmake, o Autotools etc. e passando para o CMake. Até agora, posso esperar que um projeto baseado no CMake entre em uma situação de compilação cruzada ou em uma instalação do VisualStudio ou precise apenas de uma pequena quantidade de limpeza, porque o projeto não foi responsável por partes somente do Windows ou apenas do OSX para a base de código. Eu realmente não posso esperar isso de um projeto baseado em SCons - e eu espero que 1/3 ou mais projetos do Autotools tenham ALGO errado, o que o impede de criar certo em qualquer contexto, exceto o host que constrói ou o Scratchbox2.


12
A seção mencionando Heartbleed diminui esse discurso frustrado. O problema foi que o OpenSSL NÃO estava usando um pacote do tipo configurador para detectar mallocs quebrados, mas reimplementando bibliotecas de sistemas e derrotando desenvolvedores de plataformas que produziam bibliotecas que detectariam falhas muito antes. Uma razão para programas de porta é que eles se tornam mais elevada qualidade como eles são menos dependentes dessas pequenas suposições você não evcen perceber que você está fazendo
Rob11311

9
O fato é que não diminui nada disso. Com o Autotools, você está preocupado em compensar coisas assim - essas reimplementações são uma EXPANSÃO desse mesmo pensamento. Levando para o próximo nível, por assim dizer. Você deve ver isso a partir desse pano de fundo ... nesse ponto, isso não diminui nada. Você não apontou a causa raiz do seu raciocínio - exatamente o que aconteceu. Estou digitando o PENSAMENTO exato que levou a isso junto com o Shellshock e alguns outros. Se estiver quebrado, você deve corrigi-lo. Se você não pode, você deve perguntar por que continuar.
precisa

5
Não duvido que as ferramentas automáticas e os scons sejam ruins, mas essa resposta faz um mau trabalho ao observar os contras do CMake (meu sistema de compilação preferido, apenas por causa do estado muito, muito triste dos sistemas de compilação). Basicamente, o CMake é um fractal de inconsistência com suporte interno para casos extremos individuais, em vez de uma abstração básica que lida com a maioria das coisas. É definitivamente a fita adesiva e o fio condutor da programação. Tenho certeza de que estou fazendo algo errado, mas ele não suporta o VisualStudio, a menos que você encontre um projeto do VS por CMakeLists.txt aceitável (eu não sou um usuário do VS, mas meus Winfriends me dizem que é ruim).
Weberc2

5
Diferente de outras ferramentas de programação odiadas , não há material suficiente para criar um livro chamado "CMake, as partes boas" (talvez um panfleto ou uma postagem no blog), e é mais um fractal de design ruim do que PHP .
precisa saber é o seguinte

2
@ JAB Os usuários do VS disseram que isso não é idiomático. De fato, o CMake foi substituído como o sistema de construção do nosso projeto, porque ninguém conseguia descobrir como produzir os referidos arquivos "idiomáticos" do Projeto VS.
Weberc2 25/05

73

Uma distinção importante deve ser feita entre quem usa as ferramentas. Cmake é uma ferramenta que deve ser usada pelo usuário ao criar o software. As ferramentas automáticas são usadas para gerar um pacote de distribuição que pode ser usado para criar o software usando apenas as ferramentas padrão disponíveis em qualquer sistema compatível com SuS. Em outras palavras, se você estiver instalando o software a partir de um tarball que foi construído usando as ferramentas automáticas, não estará usando as ferramentas automáticas . Por outro lado, se você estiver instalando um software que usa o Cmake, está usando o Cmake e deve tê-lo instalado para compilar o software.

A grande maioria dos usuários não precisa ter os autotools instalados em suas caixas. Historicamente, muita confusão foi causada porque muitos desenvolvedores distribuem tarballs malformados que forçam o usuário a executar o autoconf para regenerar o script de configuração, e esse é um erro de empacotamento. Mais confusão foi causada pelo fato de que a maioria das principais distribuições linux instala várias versões dos autotools, quando eles não deveriam estar instalando nenhum deles por padrão. Ainda mais confusão é causada pelos desenvolvedores que tentam usar um sistema de controle de versão (por exemplo, cvs, git, svn) para distribuir seu software em vez de criar tarballs.


5
É verdade, embora você faça parecer ruim usar um VCS para distribuir software. Se o conteúdo de um checkout ou clone é o mesmo de um tarball, por que você recomendaria o tarballs?
precisa

5
@Oor Eu não entendo sua pergunta. Todos os projetos em que trabalho produzem um tarball que é diferente do check-out do VCS. Manter as duas distintas ajuda na distribuição confiável.
William Pursell

13
É verdade que muitos projetos pedem às pessoas que usem o VCS para obter a versão mais recente, mas isso é apropriado apenas para desenvolvedores. Infelizmente, muitos usuários não conseguem entender a distinção entre o tarball de lançamento e o VCS. Tentar construir a partir do VCS impõe mais dependências. O usuário pode precisar asciidocou help2manou doxygenou, o que é mais importante, a combinação correta de autotool. Esse tem sido um enorme problema de marketing para as ferramentas automáticas. Os usuários pensam erroneamente que precisam do autoconf instalado porque não entendem a diferença entre o tarball e o VCS.
William Pursell

3
Por que um projeto não pode distribuir a saída do Cmake, arquivos de projeto e Makefiles para plataformas comuns, por exemplo) Win, Linux e MacOSX? Parece mesma situação com lex / yacc ferramentas, você incluir o código C genarated para que possa ser construído em plataformas sem as ferramentas
Rob11311

3
Embora eu ache que os pontos mencionados nesta discussão estejam corretos, acredito que essa discussão está faltando. O usuário precisa instalar várias outras coisas e se ele precisa ou não instalar o cmake não deve ser um grande problema. Eu me preocuparia mais com as bibliotecas, a cadeia de ferramentas do compilador e outras ferramentas necessárias para criar o software.
lanoxx

24

Não se trata de padrões de codificação GNU.

Os benefícios atuais dos autotools - especificamente quando usados ​​com o automake - é que eles se integram muito bem à criação da distribuição Linux.

Com o cmake, por exemplo, é sempre "foi -DCMAKE_CFLAGS ou -DCMAKE_C_FLAGS que eu preciso?" Não, também não é "-DCMAKE_C_FLAGS_RELEASE". Ou -DCMAKE_C_FLAGS_DEBUG. É confuso - no autoconf, é apenas ./configure CFLAGS = "- O0 -ggdb3" e você o tem.

Em integração com infraestruturas de construção, o scons tem o problema que você não pode usar make %{?_smp_mflags}, _smp_mflagsneste caso, uma macro RPM que se expande aproximadamente para a energia do sistema (o administrador pode configurá-lo). As pessoas colocam coisas como -jNCPUS aqui em seu ambiente. Com os scons que não estão funcionando, os pacotes que utilizam scons podem ser distribuídos em serial apenas em distros.


8
+1, e o mundo seria um lugar melhor se isso fosse verdade. Infelizmente, ./configure CFLAGS=-O0falha frequentemente com pacotes que sobrescrevem CFLAGS no makefile e exigem que o usuário execute ./configure --enable-debug. (por exemplo tmux).
William Pursell

2
Não é mais confuso do que o Autotools e, como William corretamente aponta, ele é preso no inferno com um CFLAGS = "<foo>" incorretamente enquadrado no makefile. Simplesmente esse é outro daqueles itens "antigos". E os exemplos do CMake são falsos ... de novo ... Você pode fazer o primeiro se não estiver especificando RELEASE ou DEBUG. FALHOU.
Svartalf 22/04

17

O que é importante saber sobre o Autotools é que eles não são um sistema de construção geral - eles implementam os padrões de codificação GNU e nada mais. Se você deseja criar um pacote que siga todos os padrões GNU, o Autotools é uma excelente ferramenta para o trabalho. Caso contrário, use Scons ou CMake. (Por exemplo, veja esta pergunta .) Esse mal-entendido comum é de onde vem a maior parte da frustração com o Autotools.


11
Os padrões GNU podem ser desabilitados no Automake com AUTOMAKE_OPTIONS = -foreignno seu Makefile.am. (Ou -foreignna sua autogen.sh. Eu acho que quase todo mundo usa isso.)
Dietrich Epp

9
Sim, mas isso controla apenas se o Automake aplica regras superficiais do GNU, como se um arquivo README é necessário. Isso não muda a premissa básica de construir um tarball no estilo GNU com regras como installchecke distclean. Se você tentar mudar esse tipo de comportamento enquanto ainda usa o Autotools, estará perdendo tempo.
Ptomato

1
Eles (em teoria) permitem que todos os pacotes de software sejam construídos e instalados exatamente da mesma maneira.
Ptomato

Em teoria, eles permitem que você lide com os compiladores e sistemas operacionais BROKEN de maneira mais apropriada do que com outras ferramentas e aplique regras superficiais, como o @ptomato destacado aqui. Se você estiver usando uma ferramenta moderna (por exemplo, GCC ou clang ... por exemplo) em um sistema operacional moderno , sem nada realmente engraçado, como Linux ou BSD * atual, você NÃO PRECISA das "regras" lá. Na verdade, eles fazem muito, muito mais trabalho para você e não podem ajudar, honestamente, na compilação cruzada. Atualmente, quase metade de todos os usos são para Linux embarcado e * BSD. POR QUE você está indo com coisas que não podem ajudá-lo lá?
Svartalf

Não sabe por que recusou a resposta, já que parece reconhecê-la em seu comentário ...?
Ptomato 22/05/19

9

Embora do ponto de vista dos desenvolvedores, o cmake seja atualmente o mais fácil de usar, do ponto de vista do usuário, as ferramentas automáticas possuem uma grande vantagem

As ferramentas automáticas geram um script de configuração de arquivo único e todos os arquivos para gerá-lo são enviados com a distribuição. É fácil entender e corrigir com a ajuda do grep / sed / awk / vi. Compare isso com o Cmake, onde muitos arquivos são encontrados em / usr / share / cmak * / Módulos, que não podem ser corrigidos pelo usuário, a menos que ele tenha acesso de administrador.

Portanto, se algo não der certo, geralmente pode ser facilmente "consertado" usando as ferramentas Standard Unix (grep / sed / awk / vi etc.) de uma maneira maluca, sem a necessidade de entender o sistema de compilação.

Você já procurou no diretório cmake build para descobrir o que está errado? Comparado com o shellscript simples que pode ser lido de cima para baixo, é bastante difícil seguir os arquivos Cmake gerados para descobrir o que está acontecendo. Além disso, com o CMake, a adaptação dos arquivos FindFoo.cmake requer não apenas o conhecimento da linguagem do CMake, mas também pode exigir privilégios de superusuário.


7
Eu não acho que problemas com Autotools são "facilmente corrigido" em comparação com CMake ...
sleske

7
Porque autotools é um sistema complexo (assim como o CMake). Se você acha que o Autotools é "facilmente corrigido" (pode haver razões para pensar isso), seria bom IMHO explicar na resposta de que maneira os problemas são mais fáceis de corrigir.
sleske

5
As ferramentas automáticas geram um script de configuração de arquivo único e todos os arquivos para gerá-lo são enviados com a distribuição. É fácil entender e corrigir com a ajuda do grep / sed / awk / vi. Compare isso com o Cmake, onde muitos arquivos são encontrados em / usr / share / cmak * / Módulos, que não podem ser corrigidos pelo usuário, a menos que ele tenha acesso de administrador. Você já procurou no diretório cmake build para descobrir o que está errado? Comparado com o shellscript simples que pode ser lido de cima para baixo, seguir os arquivos Cmake gerados para descobrir o que está acontecendo é bastante difícil
arquivado em

2
Sim, isso faz sentido, obrigado. Tomei a liberdade de adicioná-lo à sua resposta. Sinta-se livre para reverter :-).
sleske

1
Você sempre pode usar sua própria versão local do cmake; não há razão para usar o que está instalado no nível do sistema. Para qualquer pessoa que trabalhe em várias plataformas, isso é completamente normal; é certamente o modo como uso o cmake na maioria das vezes.
James Moore
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.