Quais são as diferenças entre Autotools, Cmake e Scons?
Quais são as diferenças entre Autotools, Cmake e Scons?
Respostas:
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:
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 ...
Os exemplos dados para o CMake neste tópico são um pouco falsos.
Contudo...
Na verdade, seus objetivos devem ditar o que você escolhe aqui.
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.
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.
asciidoc
ou help2man
ou doxygen
ou, 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.
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_mflags
neste 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.
./configure CFLAGS=-O0
falha frequentemente com pacotes que sobrescrevem CFLAGS no makefile e exigem que o usuário execute ./configure --enable-debug
. (por exemplo tmux
).
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.
AUTOMAKE_OPTIONS = -foreign
no seu Makefile.am
. (Ou -foreign
na sua autogen.sh
. Eu acho que quase todo mundo usa isso.)
installcheck
e distclean
. Se você tentar mudar esse tipo de comportamento enquanto ainda usa o Autotools, estará perdendo tempo.
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.