Usando Makefile em vez de arquivos de solução/projeto no Visual Studio (2005)

Question

Alguém tem experiência no uso de makefiles para compilações do Visual Studio C++ (no VS 2005) em vez de usar a configuração do projeto/solução.Para nós, a maneira como o projeto/soluções funcionam não é intuitiva e leva à explosão de configuração quando você tenta ajustar compilações com sinalizadores de tempo de compilação específicos.

No Unix, é muito fácil configurar um makefile que tenha suas opções padrão substituídas pelas configurações do usuário (ou outra configuração).Mas fazer esse tipo de coisa parece difícil no Visual Studio.

A título de exemplo, temos um projeto que precisa ser construído para 3 plataformas diferentes.Cada plataforma pode ter diversas configurações (por exemplo, depuração, liberação e várias outras).Um dos meus objetivos em um projeto recém-formado é ter uma solução que possa fazer com que todas as plataformas sejam construídas juntas, o que facilita a construção e o teste de alterações de código, já que você não precisa abrir três soluções diferentes apenas para testar seu código.Mas o visual studio exigirá 3 * (número de configurações básicas).ou sejaDepuração de PC, depuração X360, depuração PS3, etc.

Parece que uma solução makefile é muito melhor aqui.Envolvido com alguns arquivos em lote ou scripts básicos, seria fácil manter a explosão de configuração no mínimo e manter apenas um pequeno conjunto de arquivos para todas as diferentes compilações que temos que fazer.

No entanto, não tenho experiência com makefiles no Visual Studio e gostaria de saber se outras pessoas têm experiências ou problemas que possam compartilhar.

Obrigado.

(postagem editada para mencionar que essas são compilações C++)

Answer 1

Encontrei alguns benefícios em makefiles com projetos grandes, principalmente relacionados à unificação da localização das configurações do projeto.É um pouco mais fácil gerenciar a lista de arquivos de origem, incluir caminhos, definições de pré-processador e assim por diante, se todos estiverem em um makefile ou outro arquivo de configuração de compilação.Com várias configurações, adicionar um caminho de inclusão significa que você precisa atualizar cada configuração manualmente por meio das complicadas propriedades do projeto do Visual Studio, o que pode se tornar bastante tedioso à medida que o tamanho do projeto aumenta.

Projetos que usam muitas ferramentas de construção personalizadas também podem ser mais fáceis de gerenciar, como se você precisar compilar shaders de pixel/vértice ou código em outras linguagens sem suporte nativo de VS.

Você ainda precisará ter várias configurações de projeto diferentes, pois precisará diferenciar a invocação da ferramenta de construção para cada configuração (por exemplo,passando diferentes opções de linha de comando para fazer).

Desvantagens imediatas que vêm à mente:

• Construções mais lentas:O VS não é particularmente rápido em invocar ferramentas externas, ou mesmo em descobrir se é necessário construir um projeto em primeiro lugar.
• Dependências estranhas entre projetos:É complicado configurar para que um dependente faça com que o projeto base seja compilado e mais complicado garantir que eles sejam construídos na ordem correta.Tive algum sucesso em conseguir que os SCons fizessem isso, mas é sempre um desafio trabalhar bem.
• Perda de alguns recursos úteis do IDE:Edite e continue sendo o principal!

Resumindo, você gastará menos tempo gerenciando as configurações do seu projeto, mas mais tempo persuadindo o Visual Studio a funcionar corretamente com ele.

Answer 2

O Visual Studio está sendo construído em cima do MSBuild arquivos de configurações.Você pode considerar os arquivos *proj e *sln como makefiles.Eles permitem que você personalize totalmente o processo de construção.

Answer 3

Embora seja tecnicamente possível, não é uma solução muito amigável no Visual Studio.Ele estará lutando com você o tempo todo.

Eu recomendo que você dê uma olhada NAnt.É um sistema de construção muito robusto onde você pode fazer basicamente tudo o que precisar.

Nosso script NAnt faz isso em cada compilação:

1. Migre o banco de dados para a versão mais recente
2. Gere entidades C# fora do banco de dados
3. Compile todos os projetos em nossa solução "mestre"
4. Execute todos os testes unitários
5. Execute todos os testes de integração

Além disso, nosso servidor de construção aproveita isso e adiciona mais 1 tarefa, que é gerar a documentação do Sandcastle.

Se você não gosta de XML, você também pode dar uma olhada em Ancinho (rubi), Sistema Bake/BooBuild (Boo), ou Psake (PowerShell)

Answer 4

Você pode usar o nant para construir os projetos individualmente, substituindo assim a solução e ter 1 solução de codificação e nenhuma solução de construção.

Uma coisa a ter em mente é que a solução e os arquivos csproj do vs 2005 e superiores são scripts msbuild.Portanto, se você se familiarizar com o msbuild, poderá controlar os arquivos existentes, para facilitar o vs e para facilitar sua implantação.

Answer 5

Temos uma configuração semelhante à que você está descrevendo.Oferecemos suporte a pelo menos três plataformas diferentes, então descobrimos que usar CMake para gerenciar as diferentes soluções do Visual Studio.A configuração pode ser um pouco dolorosa, mas se resume à leitura da documentação e de alguns tutoriais.Você deve ser capaz de fazer praticamente tudo o que pode, acessando as propriedades dos projetos e da solução.Não tenho certeza se você pode ter todas as três plataformas convivendo juntas na mesma solução, mas você pode usar CruiseControl para cuidar de suas compilações e executar seus scripts de teste com a freqüência necessária.