Microsoft Developer Network > Página Inicial dos Fóruns > Visual C++ General > Avoiding recompilation of C++ modules used in multiple projects
Fazer uma PerguntaFazer uma Pergunta
 

RespondidoAvoiding recompilation of C++ modules used in multiple projects

  • quarta-feira, 4 de novembro de 2009 13:40gg3 Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     
    I have an unmanaged C++ DLL. In my solution is a VC project for the DLL, and a separate project, Win32 Console App, that contains my unit tests.

    My test project compiles several .cpp files from the DLL project, so that the symbols defined therein can resolve at runtime.

    When I build my solution, for every .cpp file that is used in my test project, I have to wait for that file to be compiled once for the DLL project, and then AGAIN for my test project.  How can I avoid this double compilation?

    I tried to make both projects share the same folder for Output and Intermediate locations, hoping that the test project would find the .obj files there and use them, but it didn't work.

    Any other ideas on how I can avoid double-compiling every one of my modules-under-test?

Respostas

  • segunda-feira, 23 de novembro de 2009 20:39gg3 Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     Respondido
    Finally found a satisfactory solution to this problem.

    What I did is change the test project's linker input additional dependencies to include the obj files for the already-compiled modules.

    For example, if my solution has two projects, DLLProject and TestProject, and TestProject calls into symbols defined in DLLProject\Module.cpp, then the TestProject linker input additional dependencies needs to include "Module" (the .obj suffix is implicit), and the linker additional library directories needs to include something like "..\DLLProject\Debug", or whatever folder your obj's are written to.

    I also used this same technique to link with a .res file (compiled form of .rc).
    • Marcado como Respostagg3 segunda-feira, 23 de novembro de 2009 20:39
    •  

Todas as Respostas

  • quarta-feira, 4 de novembro de 2009 15:00«_Superman_»MVPMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     
    You could try and make pre-compiled headers out of the .cpp files that you need to test.
    The unit tests could then be made to use those pre-compiled headers.

    You can change the settings by right clicking on the .cpp file in solutions explorer and selecting properties.
    In the Configuration Properties -> C/C++ -> Precompiled Headers change the Create/Use Precompiled Header option.


    «_Superman_»
    Microsoft MVP (Visual C++)
    • Marcado como RespostaNancy ShaoMSFT, Moderadorquarta-feira, 11 de novembro de 2009 3:20
    • Não Marcado como Respostagg3 quarta-feira, 11 de novembro de 2009 16:47
    •  
  • quarta-feira, 11 de novembro de 2009 16:48gg3 Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     
    I'd rather not make all my .cpp files precompiled headers, because this project is in active development.

    If I understand precompiled headers right, they're not appropriate for code that changes often.
  • quinta-feira, 12 de novembro de 2009 4:39Brian MuthMVPMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     
    The problem I see is that the test code is using the same cpp files. It's better to consider building a DLL out of the common cpp files and then use test code that calls the DLL.
  • segunda-feira, 16 de novembro de 2009 12:45gg3 Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     
    You mean a DLL separate from my primary project DLL?  (The code that I'm testing is already being built into a DLL, a VSPackage, actually.)  Wouldn't I then run into the same re-compilation issues when building this DLL?

    Further, my test program can't just call into the primary project DLL because many of the functions I'm testing aren't exported in the DLL.
  • segunda-feira, 23 de novembro de 2009 20:39gg3 Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     Respondido
    Finally found a satisfactory solution to this problem.

    What I did is change the test project's linker input additional dependencies to include the obj files for the already-compiled modules.

    For example, if my solution has two projects, DLLProject and TestProject, and TestProject calls into symbols defined in DLLProject\Module.cpp, then the TestProject linker input additional dependencies needs to include "Module" (the .obj suffix is implicit), and the linker additional library directories needs to include something like "..\DLLProject\Debug", or whatever folder your obj's are written to.

    I also used this same technique to link with a .res file (compiled form of .rc).
    • Marcado como Respostagg3 segunda-feira, 23 de novembro de 2009 20:39
    •  
  • segunda-feira, 23 de novembro de 2009 20:57Brian MuthMVPMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     
    That's very clever!