No tutorial anterior vimos como instalar e como criar um programa de teste no visual, agora vamos nos aprofundar um pouco mais no sistema de build do visual. Sobre o Visual C++ 2010 Este artigo foi escrito usando como base o Visual C++ 2008. Pouco muda no processo de build da versão 2010 e não vemos necessidade um artigo apenas sobre ele. Caso tenha problemas na instalação, deixe um comentário aqui que ajudaremos no que for possível Internamente na versão 2010 a Microsoft refez todo sistema de build e agora ele é todo baseado no Microsoft Build. Mas para o usuário pouco mudou na interface do Visual, que na verdade ganhou novas funcionalidades e manteve as antigas. Caso tenha algum problema de build nessa versão, não deixe de postar nos comentários para que possamos ajudar. Configurações de Build O visual por padrão possui duas configurações de build, a debug e a release. Cada versão permite que o usuário configure o compilador de maneiras totalmente diferentes, além de ser possível criar quantas configurações forem necessárias. Estas configurações são uteis para permitir, por exemplo, desabilitar qualquer otimização do compilador e facilitar a depuração de código (fato que já ocorre na configuração Debug gerada quando um projeto é criado), sendo assim, a versão debug é geralmente usada apenas pelos desenvolvedores. Já a versão release liga as otimizações do compilador e (geralmente) desliga a geração de informações de debug, sendo esta usada para se realizar um build quando queremos enviar o software ao usuário final. A configuração atual pode ser visualizada no topo da janela do visual, próximo as opções de 1 / 7
menu: Na figura acima vemos que a configuração ativa é a Debug, clicando na caixa de seleção é possível alterar a configuração a ser usada no próximo build. Além das configurações de build, é possível especificar uma plataforma para cada configuração, como por exemplo Win32 e Win64, como nunca trabalhei com desenvolvimento multi-plataforma no visual (nos projetos multi-plataforma que trabalhei usávamos uma IDE para cada ambiente) não vou me aprofundar nesse item. Opções do Menu Build Na figura abaixo podemos ver as opções do menu build do visual, que são descritas a seguir: 2 / 7
Vemos Note por 1. 2. 3. 4. que Build: Solução Projeto: Lote Compilar: que os (Batch): este o menu os (solution): este comandos de compila build de comandos compilação aqui é apenas divido que apenas afetam que em o são arquivo afetam quatro apenas múltiplas basicamente: sendo seções, toda o projeto configurações. a editado. alterados solução. sendo e suas estas: completa. e dependências. Detalhe editado, solução, comando uso - estes. de Rebuild: Clean: dependências que podem os apenas comandos apenas os este afetar ao apaga projeto em as da suas mais seção relacionados os selecionado, apaga arquivos dependências, detalhes projeto todos gerados. ao vão no escolha projeto próximo afetar arquivos se existirem não tutorial. opções dependências gerados, afetam múltiplos unicamente forçando item projetos também, Project dependências uma o projeto dentro Only. para rê-compilação aplicar de Veremos sendo afetadas umao o Opções de Runtime O runtime (no caso do visual) é a forma como seu projeto é associado a biblioteca padrão do C ou C++ (a libc), que no caso do visual pode ser uma dll, as famosas MSVC???.lib, onde??? varia de acordo com a versão e tipo de build, ou então, uma lib que é linkada diretamente com seu projeto. Mas para que especificar uma biblioteca C/C++, não deveriam ser iguais? Sim, deveriam, mas a Microsoft disponibiliza dois tipos básicos, uma versão debug e outra versão release. A versão debug da libc gera informações extras de depuração que veremos em detalhes no tutorial sobre como usar o depurador do visual, já a versão release não possui essas informações e é construída com todas as otimizações possíveis. Além da versão debug e release, existem para cada uma delas a versão DLL e não DLL. A diferença entre elas é que na versão DLL, seu código é linkado com a MSVC???.dll, na versão não dll (estática), o seu código é linkado diretamente com o arquivo lib não precisando da dll para ser executado. 3 / 7
Para configurar o runtime sendo usado basta clicar com o botão direito do mouse sobre um projeto, e escolher Properties : Na janela que abrir, basta expandir a Configuration Properties, depois o item C/C++, e clicar em Cod e Generation, do lado deve surgir então o item Runtime Library, como na figura abaixo: 4 / 7
As (nesse Detalhe ser Um versão da - janela opções usadas detalhe Multi-threaded inherit caso para que são: com que from cada a todas configurações. solução) código pode project configuração, as (/MT): DLL Debug libs passar ou multi-thread defaults: (/MD): são configuração versão (/MTd): DLL despercebido especificadas a versão (/MDd): este configuração release mesma (antigamente simplesmente release padrão. mesma multi sobre anterior, como sendo multi thread, da a existia multi-threaded, janela anterior, mas thread, usa utilizada essa também versão a configuração mas é propriedades a fica debug. para versão a isso no opção canto linkagem indica para debug. single é um superior que linkagem projeto dinâmica. thread). existe elas esquerdo podem estática. pai uma Escolhendo o Runtime A escolha do runtime depende muito do tipo de projeto, e a decisão se baseia entre versão DLL ou não DLL, sendo debug e release escolhidos de acordo com o tipo de build. A versão DLL é recomendada se seu projeto utiliza dlls, isso é necessário porque se o seu projeto usar a versão não dll da libc, cada dll e o exe do seu programa vão ter sua própria hea p. Como cada módulo possui sua própria heap, a memória alocada em um módulo (dll ou exe), utilizando new ou malloc, tem quer ser liberada apenas no mesmo módulo, a estrutura do programa fica como no exemplo abaixo: 5 / 7
Já o mesmo programa utilizando a versão da libc para dlls, fica com a estrutura como na figura abaixo: Sendo assim, se seu projeto utiliza dlls, é recomendável linkar ele apenas com a versão dll da libc. Arquivos Gerados no Build Na configuração padrão de projetos do visual, ele cria duas sub-pastas uma para os builds de debug, e outra para release: Nestas duas pastas são colocados os arquivos gerados durante o build, no caso do build de release do meu programa de testes: 6 / 7
Exceto build. gerado, Outro qualquer visual mais sobre a dentro figuration, Output que deve opção visual indica simples Isso detalhe o os surgir Directory, por projeto que permite gera um Properties significa o hello.exe, é diretório então ou consiste que novamente. suficiente todos modificar como Solution a que opção usado: todos os em para o arquivos acessar a conteúdo Explorer, pasta enviar este outros não usada programa as esse destas e arquivos propriedades causa clicando programa para pastas funcionar. problema armazenar são utilizados é para Properties ), todo projeto algum, alguem gerado arquivos apenas (clicando basta pelo janela executar pelo gerados visual, enviar com General, visual que o removendo o botão e arquivo abrir, build durante a que maneira direito que fica selecione exe umo Con O Isso $(ConfigurationName) configuração alteração Alterando temporários No caminho próximo na verdade o padrão arquivo valor (como tutorial sendo são da é arquivos exe, usada. opção duas um vamos contém vai pouco variáveis ser Intermediate Pode-se obj). ver respectivamente ser estranho, como gerados de por instalar ambiente exemplo Directory pois no consiste a diretório o Windows criadas modificar de: bin. pelo SDK da $(SolutionDir)$(ConfigurationName). para: o solução visual, diretório no $(SolutionDir)bin, visual. sendo e de o diretório destino que da dos com arquivos esta e 7 / 7