Shadow build – Chega de repositórios sujos após uma compilação. Compilar seu código dentro do repositório é opcional, você precisa apenas criar um diretório qualquer fora da sua árvore e chamar o script de configuração do seu projeto (configure). Existem várias situações onde isto é especialmente necessário: compilar a mesma árvore de código para diferentes plataformas ou quando seu código fonte está localizado em um storage lento (como um compartilhamento de rede ou uma partição criptografada).

Integração com testes automatizados – Desenvolvimento orientado a testes tem sido cada vez mais comum e provou ser uma importante ferramenta para detectar regressões. Este template provê mais do que um modo fácil de rodar seus testes (digitando “make check”), mas um relatório gráfico mostrando quão abrangentes seus testes são usando LCOV.

LCOV mostrando a cobertura dos unit tests

Documentação de código – Desenvolvedores em geral são preguiçosos se tratando de escrever documentos, a não ser que você lhes dê uma forma fácil de ver o o belo resultado de uma documentação bem escrita. Após digitar “make doc”, uma página HTML é automaticamente gerada agrupando toda a informação extraídas dos markups qdoc3 do seu código fonte.

Documentação extraída da classe Foobar

Internacionalização – Um buildsystem moderno precisa prover um jeito fácil para os tradutores atualizarem os arquivos de tradução. Precisamos ter em mente que tradutores não são necessariamente desenvolvedores e eles podem não gostar de ter que vasculhar o código fonte em busca de strings para tradução. Este template fornece uma integração com lupdate e lrelease – ferramentas i18n do Qt – criando todos os aquivos .ts necessários ao Qt Linguist.

Use o Qt Linguist para editar os arquivos de tradução

Fácil depuração – É meio óbvio que um buildsystem também deve gerar uma versão do software especial para depuração. Você também não precisa instalar esta versão no sistema para fazer testes (pelo menos no Linux).

Empacotamento – Seu software precisa ser de fácil distribuição. Adicionamos o suporte a empacotamento para Debian como exemplo neste template para demonstrar como é fácil fazer um pacote baseado neste buildsystem. Alguém anima contribuir com o empacotamento RPM?

Considerações finais

Só fiz testes deste template no Linux. Infelizmente algumas features só vão funcionar se você estiver usando GCC, como por exemplo a cobertura de código dos testes automatizados.

A última versão para download está disponível aqui. Você também pode navegar pelo repositório git do template. Lembre-se: patches e sugestões são sempre bem-vindos.

Mais instruções de uso (em inglês) no aquivo BUILD.

Se você é corajoso, compile seu próprio pacote com estes patches aqui.

A extensão do VIM chamada  Omni Completion fazia a mesma coisa de forma satisfatória quando usando C, mas o fato é que nunca me acostumei a usar isso: ctags + rápida olhada nos headers eram o suficiente até então, mas foi quando o Qt e suas classes com milhões de atributos e métodos chegaram na minha vida. Hoje, enquanto queimava uns neurônios tentando lembrar o nome de um método da classe QSomething eu tive a brilhante idéia de usar  auto-completion do VIM (porque não?). Decepcionado, descobri que o Omni Completion não suporta C++ nativamente.

O Oráculo me disse algo a respeito de um add-on chamado OmniCppComplete. Poucos minutos foram o suficiente para instalar e ver quão legal é o plugin. Apenas o pop-up automático sugerindo nome de atributos que é irritante, mas pode-se facilmente desabilitá-lo e usar o bom e velho ^X^O sob demanda.

É claro que não há nada novo aqui (a primeira versão do OmniCpp data de 2006), mas você pode ser como eu, receoso em relação a testar novos add-ons do VIM, porque a maioria é lixo. Apenas poucos merecem a honra de estar no meu .vimrc. Este post portanto é para encorajar usuários do VIM a dar uma chance ao OmniCpp e se tornar mais efetivo.

OmniCppComplete em ação