C ++ Build Systems - O que usar? [fechadas]

136

Estou pensando em iniciar um novo projeto em C ++ - apenas no meu tempo inicial - e estou investigando os sistemas de compilação disponíveis. Parece que a resposta é "Muitos, e todos são horríveis".

Os recursos que eu especificamente preciso para isso são:

Suporte para C ++ 11
Plataforma cruzada (Linux como destino principal, mas capaz de desenvolver pelo menos também o Windows)
Suporte de teste de unidade decente
Suporte para vários módulos para separar o código
Suporte para geração de código (usando asn1c ou protobuf - ainda não 100% seguro)
De fácil manutenção

Agora, eu sei que posso fazer de 1 a 4 das pessoas usando o CMake e o Autotools com bastante facilidade. Provavelmente também com SCons e Waf e os outros dois também. O problema é que nunca descobri como fazer a geração de código corretamente usando-os - ou seja, arquivos de origem que não existem até o primeiro processo de compilação ser executado, portanto, os arquivos de origem que o sistema de compilação deve poder converter em código executável mas na verdade não sabe até que a compilação seja iniciada ... (o ASN1C em particular gera dezenas de arquivos de cabeçalho e de origem que devem poder trabalhar juntos, e o conjunto real de arquivos gerado depende do conteúdo do seu arquivo asn) também o fato de que nada disso é especialmente fácil de manter - o CMake e o Autotools têm seu próprio conjunto enorme de scripts que você precisa gerenciar para que eles funcionem,

Então - quais sistemas de compilação são recomendados para algo assim? Ou ficarei preso com make files e shell scripts por enquanto?

c++ build

— Graham
fonte

11

"Parece que a resposta é 'Muitos, e todos são horríveis'" é minha impressão também (com a adição de 'horrível do meu ponto de vista'; não gosto de generalizar demais com termos como estes ) Na verdade, eu criei o meu próprio por esse mesmo motivo, e funcionou melhor do que o esperado, pois faz o que eu quero e como eu sempre quis que as coisas funcionassem. Por algo um pouco menos demorado, você provavelmente precisará examinar as ferramentas existentes e escolher uma que ofereça menos dores de cabeça que as outras.

— Christian Stieber

4

Tente tup .

— Kerrek SB

Veja também: stackoverflow.com/q/3349956

— ergosys

8

Que tipo de suporte C ++ 11 você espera de um sistema de construção? Isso é algo que você obtém do compilador, o sistema de compilação não analisa nem lê os arquivos de origem reais, apenas os transmite para quem precisa deles, não?

— Baruch

5

É verdade, mas seria fácil dizer ao compilador para usar o suporte ao C ++ 11. O g ++ precisa de um sinalizador, chama um conjunto diferente, o msvc aparentemente não precisa de nenhum e assim por diante. Além disso, o suporte para detectar o que estão disponíveis seria útil c ++ 11 características como que também difere entre compiladores ...

— Graham

117

+1 em "Muitos, e são terríveis".

Mas, o "mais rico" e "o mais escalável" é provavelmente o CMake , que é um gerador de Makefile (também gera MSVC ++ *.proj/ *.sln) nativo . Sintaxe estranha, mas uma vez que você aprende, pode permitir que você gere compilações para diferentes plataformas. Se eu "começasse de novo", provavelmente usaria CMake. Ele deve lidar com sua lista, embora sua "geração de código" possa assumir uma "vida própria" além do sistema de compilação, dependendo do que você deseja fazer. (Ver abaixo.)

Para projetos simples, o gerador QMake está ok (você não precisa usar as bibliotecas Qt para usar o QMake). Mas você não está descrevendo "simples" - geração de código e "fases extras" significa que provavelmente deseja CMakeou algo com uma API rica para suas próprias extensões, como Scons(ou Waf).

Usamos Scons no trabalho. Produz "build-proof-builds", mas é realmente lento. Nenhum outro sistema será tão à prova de balas quanto Scons. Mas é lento. Está escrito em Python e ampliamos a interface para nossa "organização do espaço de trabalho" (onde apenas especificamos dependências de módulo), e isso faz parte da Sconsintenção do projeto (esse tipo de extensão por meio do Python). Conveniente, mas as compilações são lentas. Você obtém compilações à prova de balas (qualquer caixa de desenvolvedor pode fazer o lançamento final), mas é lento. E é lento. Não esqueça que, se você usar Scons, porém, isso é lento. E é lento.

Faz-me mal pensar que uma década depois do ano 2000, ainda não temos carros voadores. Provavelmente teremos que esperar mais cem anos ou algo para obtê-los. E provavelmente todos nós estaremos voando em nossos carros voadores que ainda estão sendo construídos com sistemas de baixa qualidade.

Sim, todos eles são horríveis.

[SOBRE GERAÇÃO DE CÓDIGO]

Sconstrabalha em "fases" e são "um pouco estáticas". Ele pode criar código que é gerado como parte da compilação (as pessoas estão fazendo isso de várias maneiras diferentes), mas isso foi descrito como "algo muito diferente do Scons".

Se é simples "pré-processar alguns arquivos e gerar arquivos de origem", não há problema (você tem muitas opções, e qmakefoi por isso que foi escrito - para o mocpré - processamento de *.hpp/*.cpparquivos).

No entanto, se você estiver fazendo isso de uma maneira "pesada", precisará criar seu próprio script. Por exemplo, tínhamos scripts como parte da compilação que consultavam os bancos de dados e geravam classes C ++ para fazer interface entre as "camadas" (no desenvolvimento tradicional de aplicativos de três camadas). Da mesma forma, geramos código-fonte de servidor / cliente por meio de IDLs e informações de versão incorporadas para permitir que vários clientes / servidores sejam executados simultaneamente com versões diferentes (para o mesmo "cliente" ou "servidor"). Muito código fonte gerado. Poderíamos "fingir" que é "o sistema de compilação", mas, na verdade, é uma infra-estrutura não trivial para "gerenciamento de configuração", da qual parte é o "sistema de compilação". Por exemplo, esse sistema precisava "derrubar" e "

— charley
fonte

37

Eu também gosto de Scons - mas acho que é lento.

— Lothar

1

Você pode fazer com que o CMake lide com a geração de código com um wrapper Makefile para executar uma segunda fase opcional quando o código é gerado. Eu era capaz de suportar rastreamento de dependência completa, saída precoce após a geração de código para desencadear uma re-cmake, etc. See: javaglue.com/javaglue.html#tag:JavaGlue e code.google.com/p/javaglue

— sdw

3

Quase dois anos depois, você ainda considera os SCons lentos? Quando eu estava escolhendo um sistema de construção, deparei-me com isso e isso contribuiu para minha decisão de seguir com o SCons.

— JBentley

2

@ Ben, isso é verdade, mas também é lento.

— Charley

2

Quem olhar para isso deve considerar Meson (que usa ninja).

— Matthew D. Scholefield

33

Você pode usar o Gradle agora: https://docs.gradle.org/current/userguide/native_software.html

Isso parece ter amadurecido bastante nos anos desde que eu postei isso originalmente. A página que diz que o projeto está "incubando" desapareceu, mas não consigo encontrar nenhum anúncio oficial removendo esse status.

— Nate Glenn
fonte

Eu concordo com Gradle. Gradle foi projetado para ser escalável. No entanto, depende da implementação do plug-in quão rápido é. Há também algumas despesas gerais para o próprio gradle. Lembre-se também de que alguns plug-ins podem precisar ser personalizados para seus casos de uso.

— JE42

Interessante ver o interesse da gradle em apoiar C ++. Espero que eles produzam um sistema de construção sólido e agradável para projetos em c ++ que todos nós estamos perdendo.

— Hbobenicio 23/10

@ obrigado squid, atualizado.

— Nate Glenn

1

Gradle é poderoso, mas simples. Sem sintaxe estranha, um único arquivo gradle.build costuma ser suficiente para criar um projeto inteiro com várias saídas executáveis (principal, testes, etc.). Nenhum despejo de arquivos em todos os diretórios de origem. Super amigável para versionamento.

— Overdrivr

1

Passei os últimos dois dias lutando com Gradle, apenas tentando criar uma biblioteca, aplicativo e gtests do "olá mundo", e não posso dizer que posso recomendá-lo para um novo projeto. As ferramentas podem estar todas lá, mas a documentação não está (dando o benefício da dúvida). Talvez aqueles que acham viável possam apontar seus recursos favoritos?

— jwm

16

Eu os encontrei, ainda não os usei pessoalmente:

Ninja , um pequeno sistema de construção focado na velocidade. O Google agora usa o Ninja para criar o Android em vez do link Make : .

Shake , um sistema de construção poderoso e rápido.

Tup , um sistema de compilação de alto desempenho. Projeto baseado em algoritmos . Análise de Tup .

Todos agora são multiplataforma e oferecem suporte ao Windows. Ainda não tenho certeza do restante de seus requisitos, pois ainda tenho que testá-los. Eles estão sendo usados no desenvolvimento comercial, a CIG escolheu Ninja. Eu usei e adoro a facilidade e a velocidade do Ninja com um gerador de projetos. Os dois primeiros são semelhantes a Scons, Ant, etc.

— leetNightshade
fonte

1

O Tup atrapalha a pesquisa de símbolos, não brinca muito bem com nenhum outro sistema de compilação (na verdade), não brinca muito bem com saídas aleatórias (como classes geradas por javacclasses internas, que são separadas em class$1.classarquivos), é mal escrito e usa hacks do sistema para conseguir o que faz. É ótimo para pequenos sistemas; inatingível para projetos maiores.

— Qix - MONICA FOI ERRADA EM 03/06

@Qix: Você não consegue manter a saída separada do seu repositório?

— Kerrek SB

1

@KerrekSB Você pode, mas esse não é o problema com a pesquisa de símbolos. O Tup usa o FUSE e monta seu próprio middleware .tup/mnt. Em seguida, ele executa todos os programas de compilação em uma pasta (ou seja .tup/mnt/@tupjob-XXXXX) como o diretório de trabalho para monitorar leituras / gravações, reforçando a configuração da compilação. Funciona bem, a menos que o caminho seja armazenado absolutamente (ou seja, com símbolos). Quando você compila um binário, o caminho do símbolo é armazenado no próprio binário. Isso significa que, quando o GDB tenta carregar os símbolos, ele procura esse tupjobcaminho, que não existe, causando erros.

— Qix - MONICA FOI ERRADA EM 03/06

Tanto o Tup quanto o Ninja são ferramentas de nível muito baixo, tão baixas ou sempre mais baixas que o Make. Eles não são adaptados ao C ++. Eu nem chamaria essas ferramentas de construir sistemas por conta própria, porque estão perdendo muitos recursos importantes de nível superior que os verdadeiros sistemas de construção oferecem para lidar com projetos complexos do mundo real. Alguns desses sistemas podem usar o Ninja como back-end.

— Johan Boulé

11

Scons é um sistema muito amigável e flexível, mas Lothar, é realmente lento.

Mas existe uma maneira de aumentar o desempenho de programas escritos em Python. Este uso do JIT. De todos os projetos conhecidos, o PyPy é uma implementação muito poderosa, de crescimento rápido e motivada, apoiada pelo JIT - Python 2.7. A compatibilidade do PyPy com o Python 2.7 é simplesmente incrível. No entanto, os Scons declarados como projeto não suportado no wiki de compatibilidade do PyPy . O Waf , por outro lado, modelado como sucessor de ferramentas automáticas baseadas em python, é totalmente suportado pela infraestrutura do PyPy. Nos meus projetos, a velocidade da montagem aumentou 5-7 vezes na transição para o PyPy. Você pode ver os relatórios de desempenho do PyPy .

Para um sistema de construção moderno e relativamente rápido, o Waf é uma boa escolha.

— aegor
fonte

Vale a pena notar que o scons agora está marcado como "Compatível" na página wiki vinculada, então, aparentemente, agora funciona com o PyPy.

— Falso Nome

8

O sistema de compilação do Google é uma boa alternativa: http://bazel.io/

— Mike B
fonte

3

"Plataforma cruzada (Linux como alvo principal, mas capaz de desenvolver pelo menos também o Windows)". A FAQ de Bazel diz "No momento, estamos trabalhando ativamente para melhorar o suporte ao Windows, mas ainda há maneiras de ser utilizável".

— Michael Mrozek

3

Não tenho certeza se é o próprio sistema ou o cara que montou o projeto, mas tive uma grande dor nas costas ao usá-lo @ work. É muito flexível (no sentido de que apenas suporta uma maneira de fazer coisas, geralmente subótima, se não assustadora), não é poderosa o suficiente, mal documentada (além dos casos básicos), tem pouca comunidade, portanto não espere que o fluxo de empilhamento venha salvar você , uma grande dependência por si só, não funciona bem com a maioria dos IDEs na maioria dos sistemas, etc, etc, etc. Portanto, a menos que você seja um fã do google - fique longe dele (aliás, existe uma versão do facebook disso, chamada Buck - para os fãs do facebook)

— Slava

Ei, achei muito fácil de usar depois de passar 6 semanas tentando fazer o CMake funcionar. Eu queria que ele baixasse dependências de terceiros e as compilasse (como eu estava acostumado a criar boas ferramentas de python e JavaScript). Isso facilitou, mas tem a desvantagem de que talvez você precise gravar seus próprios arquivos bazel para terceiros que não o suportam. Eles precisam de um repositório central para armazená-los na sua conta.

— CpILL 26/04/19

6

Eu usei SCons e estou impressionado com este sistema de compilação. O SCons é extensível pelo python e pelo próprio python - é ótimo, porque o Python tem tudo o que você precisa, apenas codifique a lógica, toda a funcionalidade de baixo nível já está implementada no SCons e no Python e é multiplataforma. Se tiver boas habilidades de programação, seus scripts de construção parecerão perfeitos e fáceis.

Make, CMake e sistemas de construção semelhantes parecem lixo de macroses. Waf é SCons analógico. Estou tentando Waf, mas os SCons serão mais amigáveis, então fiquei com os SCons.

Pela opinião da multidão, os SCons são muito lentos, mas no meio de um projeto não vi diferença entre make e SCons pela velocidade de construção. Em vez disso, o SCons trabalhou bem com compilações paralelas, enquanto o make tem grandes problemas.

Além disso, o SCons permite configurar, compilar, implantar, gerar configurações a partir de modelos, executar testes e executar qualquer outra tarefa que possa ser feita, como codificação com python e SCons - tudo em um. Essa é uma vantagem muito grande.

Para um projeto simples, o CMake também é uma boa escolha.

— Torsten
fonte

3

Meu problema aqui é que sou mimada. Sou desenvolvedor Java de profissão, e ferramentas como Gradle no mundo Java são o tipo de ferramenta que eu realmente gostaria de ter para o desenvolvimento de C ++. Posso configurar um projeto gradle, sem dependências externas, usando um arquivo de construção de linha única. É isso aí. Projectos multi-módulo que têm inúmeras dependências ainda são fáceis de fazer bem, e realmente pesam muito menos configuração do que até mesmo um simples C ++ projeto ...

— Graham

Eu tive problemas ao criar outros pacotes que usam o Scons porque não abstraem os sinalizadores de configuração do sistema, como -I incluem dirs e -L library dirs. Não é necessário CFLAGS, você geralmente precisa modificar cada script scons para que ele fique no lugar certo.

— ACyclic 21/09/16

5

só para adicionar meus centavos: premake

http://industriousone.com/premake

há também uma página da web dedicada no wiki.

— user827992
fonte

2

Infelizmente, o Premake não suporta a geração de código de acordo com os requisitos do OP. E eu não chamaria seu suporte de teste de unidade de "decente", embora haja algumas coisas que você pode fazer.

— precisa saber é o seguinte

@ergosys percebo que formiga não é mencionada, anttambém suporta C / C ++, veja se isso é bom para você, é o sobrenome que tenho, eu apenas uso Makefiles e Cmake para isso.

— user827992

2

Você pode usar o Ceedling . Observe que, no entanto, ele suporta apenas C no momento e está fortemente acoplado às estruturas de teste Unity e CMock do autor.

Ele pode ser bifurcado e modificado para funcionar com um compilador C ++ e uma estrutura de teste / simulação de unidade com bastante facilidade.

Tup também é uma menção digna. É extremamente rápido, mas não sabe nada sobre estruturas de teste etc., o que significa que você terá que escrever seu próprio sistema de compilação usando o Tup. Se você planeja fazer TDD, o Tup provavelmente é o caminho a percorrer.

— thegreendroid
fonte