como ter alvos make para diretórios de depuração e compilação de lançamento separadas?

Question

Eu estou procurando sugestões para lidar correctamente com depuração e compilação de lançamento subdiretórios separados, em um sistema de makefile recursiva que usa o alvo $ (SUBDIRS) conforme documentado no gnumake manual para aplicar alvos make Para (código-fonte) subdiretórios.

Especificamente, eu estou interessado em possíveis estratégias para implementar metas como 'all', 'clean', 'realclean' etc. que quer assumir uma das árvores ou deve funcionar em ambas as árvores estão causando um problema.

Nossos makefiles atuais usam uma variável COMPILETYPE que é configurado para depuração (padrão) ou Release (a 'liberação' target), que faz corretamente as compilações, mas limpar e fazer tudo funcionar apenas na árvore de depuração padrão. Passando para baixo a variável COMPILETYPE fica desajeitado, pois se e como fazer isso depende do valor do alvo real.

Answer 1

Uma opção é ter metas específicas nos subdiretórios para cada tipo de compilação. Então, se você fizer um "fazer tudo" no nível superior, que olha para COMPILETYPE e invoca "fazer all-debug" ou "fazer all-release", conforme apropriado.

Como alternativa, você pode definir uma variável de ambiente COMPILETYPE no nível superior, e têm cada negócio sub-Makefile com ele.

A solução real é a de não fazer um make recursiva, mas para incluir makefiles em subdiretórios no arquivo de nível superior. Isso permitirá que você facilmente construir em um diretório diferente do que as vidas de origem em, assim você pode ter build_debug e build_release diretórios. Ele também permite make paralelo ao trabalho (make -j). Consulte recursiva Faça prejudicial considerado para uma explicação completa.

Answer 2

Se você é disciplinado em sua Makefiles sobre o uso de sua variável $ (COMPILETYPE) para referenciar o diretório de construção apropriado em todas as suas regras, de regras que geram arquivos de objeto, a normativa para limpar / dist / etc, você deve ser bem.

Em um projeto em que trabalhei, tivemos uma variável $ (BUILD) que foi definido para (o equivalente a) Build- (COMPILETYPE) que fez regras um pouco mais fácil uma vez que todas as regras só poderia se referir a $ ( BUILD), por exemplo, limpo seria rm -rf $ (BUILD).

Enquanto você estiver usando $ (MAKE) para invocar sub-marcas (e usando GNU make), você pode automaticamente exportar a variável COMPILETYPE para todas as sub-marcas, sem fazer nada de especial. Para mais informações, consulte a seção relevante do GNU make Manual .

Algumas outras opções:

• Força um re-build quando a mudança bandeiras do compilador, adicionando uma dependência para todos os objetos em uma meta-arquivo que rastreia o último jogo usado de bandeiras do compilador. Veja, por exemplo, como Git gerencia arquivos objeto .
• Se você estiver usando autoconf / automake, você pode facilmente usar uma compilação separada fora de lugar pasta de compilação de seus tipos de compilação diferentes. por exemplo, cd /scratch/build/$COMPILETYPE && $srcdir/configure --mode=$COMPILETYPE && make o que levaria a construção do tipo fora do Makefiles e em configure (onde você tem que adicionar algum suporte para especificar suas bandeiras compilação desejada com base no valor de --mode em sua configure.ac)

Se você dar alguns exemplos mais concretos de suas regras atuais, talvez você vai ter algumas sugestões mais concretas.