Unit Test Output & Project Structure Advice — CMake + Google Test Framework












19














I'm new to CMake and I'm using the Google Test Framework. I've looked for more complex examples of combining CMake and the Google testing framework, but I've not turned up much luck. I was hoping that someone could provide their opinion on the setup I've arrived at and answer a question for me. Here's the basic project structure:




ProjectFolder

-CMakeLists.txt

/build

/include

  -all my .h files

/src

  -CMakeLists.txt

  -all my .cpp files

/tests

  -CMakeLists.txt

  /gtest

    -Google's CMakeLists.txt

  /mocks

    -CMakeLists.txt

    -cpp and h files for mocks



In a nutshell the root cmake file adds src and tests as subdirectories. The src cmake file globs the cpp files into a library. The tests cmake file adds mocks and gtest as subdirectories. The mock cmake file globs all of its cpp files into a second library. Finally the cmake file in the tests folder links the src library, google libraries, and the mocks libraries with the unit test executables.



What I eventually get are several executables: objA_unittest, objB_unittest, etc



A few things:




  1. To build all of this and still keep my project directory fairly clean I cd into the build folder and run "cmake .." This seems to work really well and I was planning on configuring vim to always run make out of this folder. Does anyone have any tips or or see any problems with this approach?


  2. I'm not fond of the idea of having to nest the google library in my project folder (particularly if I eventually have several projects that use it), but as it seems to be highly suggested that you not precompile the google libraries I can see no way around this. However, if anyone does know of a better way, I would love to hear it.


  3. Running the tests. I like that all I have to do is run "make test" to execute all of my unit tests with ctest. However, I've discovered that I don't like the output very much. Each unit test executable contains several different unit tests. Running these directly provides Google's very verbose feedback. If one of the tests in an executable fails I know exactly what test fails and why. Previously, I used a makefile and at the end of the makefile I simply executed all of the tests. I first attempted to fix this by creating a custom build target in cmake. However, it only executes the first command. I either need a way to get more verbose output from CTest OR I need a way to automatically output a bash script or something similar from CMake to execute each unit test executable. In other words, I have the cmake file set up now so I only have to add the unit test in one place to generate the executable, and I don't want to have to remember to add it to a second place if I can avoid it. Does anyone have any experience that would be helpful in this point?



Thanks very much in advance.










share|improve this question





























    19














    I'm new to CMake and I'm using the Google Test Framework. I've looked for more complex examples of combining CMake and the Google testing framework, but I've not turned up much luck. I was hoping that someone could provide their opinion on the setup I've arrived at and answer a question for me. Here's the basic project structure:




    ProjectFolder

    -CMakeLists.txt

    /build

    /include

      -all my .h files

    /src

      -CMakeLists.txt

      -all my .cpp files

    /tests

      -CMakeLists.txt

      /gtest

        -Google's CMakeLists.txt

      /mocks

        -CMakeLists.txt

        -cpp and h files for mocks



    In a nutshell the root cmake file adds src and tests as subdirectories. The src cmake file globs the cpp files into a library. The tests cmake file adds mocks and gtest as subdirectories. The mock cmake file globs all of its cpp files into a second library. Finally the cmake file in the tests folder links the src library, google libraries, and the mocks libraries with the unit test executables.



    What I eventually get are several executables: objA_unittest, objB_unittest, etc



    A few things:




    1. To build all of this and still keep my project directory fairly clean I cd into the build folder and run "cmake .." This seems to work really well and I was planning on configuring vim to always run make out of this folder. Does anyone have any tips or or see any problems with this approach?


    2. I'm not fond of the idea of having to nest the google library in my project folder (particularly if I eventually have several projects that use it), but as it seems to be highly suggested that you not precompile the google libraries I can see no way around this. However, if anyone does know of a better way, I would love to hear it.


    3. Running the tests. I like that all I have to do is run "make test" to execute all of my unit tests with ctest. However, I've discovered that I don't like the output very much. Each unit test executable contains several different unit tests. Running these directly provides Google's very verbose feedback. If one of the tests in an executable fails I know exactly what test fails and why. Previously, I used a makefile and at the end of the makefile I simply executed all of the tests. I first attempted to fix this by creating a custom build target in cmake. However, it only executes the first command. I either need a way to get more verbose output from CTest OR I need a way to automatically output a bash script or something similar from CMake to execute each unit test executable. In other words, I have the cmake file set up now so I only have to add the unit test in one place to generate the executable, and I don't want to have to remember to add it to a second place if I can avoid it. Does anyone have any experience that would be helpful in this point?



    Thanks very much in advance.










    share|improve this question



























      19












      19








      19


      11





      I'm new to CMake and I'm using the Google Test Framework. I've looked for more complex examples of combining CMake and the Google testing framework, but I've not turned up much luck. I was hoping that someone could provide their opinion on the setup I've arrived at and answer a question for me. Here's the basic project structure:




      ProjectFolder

      -CMakeLists.txt

      /build

      /include

        -all my .h files

      /src

        -CMakeLists.txt

        -all my .cpp files

      /tests

        -CMakeLists.txt

        /gtest

          -Google's CMakeLists.txt

        /mocks

          -CMakeLists.txt

          -cpp and h files for mocks



      In a nutshell the root cmake file adds src and tests as subdirectories. The src cmake file globs the cpp files into a library. The tests cmake file adds mocks and gtest as subdirectories. The mock cmake file globs all of its cpp files into a second library. Finally the cmake file in the tests folder links the src library, google libraries, and the mocks libraries with the unit test executables.



      What I eventually get are several executables: objA_unittest, objB_unittest, etc



      A few things:




      1. To build all of this and still keep my project directory fairly clean I cd into the build folder and run "cmake .." This seems to work really well and I was planning on configuring vim to always run make out of this folder. Does anyone have any tips or or see any problems with this approach?


      2. I'm not fond of the idea of having to nest the google library in my project folder (particularly if I eventually have several projects that use it), but as it seems to be highly suggested that you not precompile the google libraries I can see no way around this. However, if anyone does know of a better way, I would love to hear it.


      3. Running the tests. I like that all I have to do is run "make test" to execute all of my unit tests with ctest. However, I've discovered that I don't like the output very much. Each unit test executable contains several different unit tests. Running these directly provides Google's very verbose feedback. If one of the tests in an executable fails I know exactly what test fails and why. Previously, I used a makefile and at the end of the makefile I simply executed all of the tests. I first attempted to fix this by creating a custom build target in cmake. However, it only executes the first command. I either need a way to get more verbose output from CTest OR I need a way to automatically output a bash script or something similar from CMake to execute each unit test executable. In other words, I have the cmake file set up now so I only have to add the unit test in one place to generate the executable, and I don't want to have to remember to add it to a second place if I can avoid it. Does anyone have any experience that would be helpful in this point?



      Thanks very much in advance.










      share|improve this question















      I'm new to CMake and I'm using the Google Test Framework. I've looked for more complex examples of combining CMake and the Google testing framework, but I've not turned up much luck. I was hoping that someone could provide their opinion on the setup I've arrived at and answer a question for me. Here's the basic project structure:




      ProjectFolder

      -CMakeLists.txt

      /build

      /include

        -all my .h files

      /src

        -CMakeLists.txt

        -all my .cpp files

      /tests

        -CMakeLists.txt

        /gtest

          -Google's CMakeLists.txt

        /mocks

          -CMakeLists.txt

          -cpp and h files for mocks



      In a nutshell the root cmake file adds src and tests as subdirectories. The src cmake file globs the cpp files into a library. The tests cmake file adds mocks and gtest as subdirectories. The mock cmake file globs all of its cpp files into a second library. Finally the cmake file in the tests folder links the src library, google libraries, and the mocks libraries with the unit test executables.



      What I eventually get are several executables: objA_unittest, objB_unittest, etc



      A few things:




      1. To build all of this and still keep my project directory fairly clean I cd into the build folder and run "cmake .." This seems to work really well and I was planning on configuring vim to always run make out of this folder. Does anyone have any tips or or see any problems with this approach?


      2. I'm not fond of the idea of having to nest the google library in my project folder (particularly if I eventually have several projects that use it), but as it seems to be highly suggested that you not precompile the google libraries I can see no way around this. However, if anyone does know of a better way, I would love to hear it.


      3. Running the tests. I like that all I have to do is run "make test" to execute all of my unit tests with ctest. However, I've discovered that I don't like the output very much. Each unit test executable contains several different unit tests. Running these directly provides Google's very verbose feedback. If one of the tests in an executable fails I know exactly what test fails and why. Previously, I used a makefile and at the end of the makefile I simply executed all of the tests. I first attempted to fix this by creating a custom build target in cmake. However, it only executes the first command. I either need a way to get more verbose output from CTest OR I need a way to automatically output a bash script or something similar from CMake to execute each unit test executable. In other words, I have the cmake file set up now so I only have to add the unit test in one place to generate the executable, and I don't want to have to remember to add it to a second place if I can avoid it. Does anyone have any experience that would be helpful in this point?



      Thanks very much in advance.







      cmake googletest






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Aug 31 '11 at 21:44







      Landon

















      asked Aug 31 '11 at 19:30









      LandonLandon

      3411210




      3411210
























          2 Answers
          2






          active

          oldest

          votes


















          11















          1. It is actually a recommended cmake practice called out-of-source build

          2. AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.

          3. I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:


          Add following lines into your top level CMakeLists.txt (before adding any tests):



          add_custom_target(test)
          macro(run_test test_target)
          add_custom_target(${test_target}_runtest
          COMMAND ${test_target} #cmake 2.6 required
          DEPENDS ${test_target}
          WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
          add_dependencies(test ${test_target}_runtest)
          endmacro()


          Next for each test add a single line to append your test to the test target:



          #add_executable(mytest ${mysources})
          run_test(mytest)





          share|improve this answer

















          • 3




            Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
            – DLRdave
            Sep 1 '11 at 11:24










          • Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
            – Landon
            Sep 2 '11 at 19:02



















          12














          Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.






          share|improve this answer





















          • I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
            – Kurt Schwehr
            Nov 18 '12 at 19:54










          • Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
            – Sergei Nikulov
            Nov 19 '12 at 8:24










          • @KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
            – Sergei Nikulov
            Dec 3 '12 at 9:37











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f7262370%2funit-test-output-project-structure-advice-cmake-google-test-framework%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          11















          1. It is actually a recommended cmake practice called out-of-source build

          2. AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.

          3. I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:


          Add following lines into your top level CMakeLists.txt (before adding any tests):



          add_custom_target(test)
          macro(run_test test_target)
          add_custom_target(${test_target}_runtest
          COMMAND ${test_target} #cmake 2.6 required
          DEPENDS ${test_target}
          WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
          add_dependencies(test ${test_target}_runtest)
          endmacro()


          Next for each test add a single line to append your test to the test target:



          #add_executable(mytest ${mysources})
          run_test(mytest)





          share|improve this answer

















          • 3




            Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
            – DLRdave
            Sep 1 '11 at 11:24










          • Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
            – Landon
            Sep 2 '11 at 19:02
















          11















          1. It is actually a recommended cmake practice called out-of-source build

          2. AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.

          3. I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:


          Add following lines into your top level CMakeLists.txt (before adding any tests):



          add_custom_target(test)
          macro(run_test test_target)
          add_custom_target(${test_target}_runtest
          COMMAND ${test_target} #cmake 2.6 required
          DEPENDS ${test_target}
          WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
          add_dependencies(test ${test_target}_runtest)
          endmacro()


          Next for each test add a single line to append your test to the test target:



          #add_executable(mytest ${mysources})
          run_test(mytest)





          share|improve this answer

















          • 3




            Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
            – DLRdave
            Sep 1 '11 at 11:24










          • Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
            – Landon
            Sep 2 '11 at 19:02














          11












          11








          11







          1. It is actually a recommended cmake practice called out-of-source build

          2. AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.

          3. I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:


          Add following lines into your top level CMakeLists.txt (before adding any tests):



          add_custom_target(test)
          macro(run_test test_target)
          add_custom_target(${test_target}_runtest
          COMMAND ${test_target} #cmake 2.6 required
          DEPENDS ${test_target}
          WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
          add_dependencies(test ${test_target}_runtest)
          endmacro()


          Next for each test add a single line to append your test to the test target:



          #add_executable(mytest ${mysources})
          run_test(mytest)





          share|improve this answer













          1. It is actually a recommended cmake practice called out-of-source build

          2. AFAIK it is not recommended to install recompiled googletest libraries in the system. So there should not be any problem if you compile it as shared or static library as part of your project build. I have used googletest 1.6.0 this way without problems on Windows, Linux, OSX and Android.

          3. I'm not sure about CTest but custom target is definitely able to run all tests for you. Here is a short solution I can suggest:


          Add following lines into your top level CMakeLists.txt (before adding any tests):



          add_custom_target(test)
          macro(run_test test_target)
          add_custom_target(${test_target}_runtest
          COMMAND ${test_target} #cmake 2.6 required
          DEPENDS ${test_target}
          WORKING_DIRECTORY "${CMAKE_BINARY_DIR}")
          add_dependencies(test ${test_target}_runtest)
          endmacro()


          Next for each test add a single line to append your test to the test target:



          #add_executable(mytest ${mysources})
          run_test(mytest)






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Sep 1 '11 at 0:29









          Andrey KamaevAndrey Kamaev

          24.5k57378




          24.5k57378








          • 3




            Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
            – DLRdave
            Sep 1 '11 at 11:24










          • Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
            – Landon
            Sep 2 '11 at 19:02














          • 3




            Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
            – DLRdave
            Sep 1 '11 at 11:24










          • Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
            – Landon
            Sep 2 '11 at 19:02








          3




          3




          Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
          – DLRdave
          Sep 1 '11 at 11:24




          Be careful: there's a pre-defined CMake target named 'test' already. Adding a custom target with that same name is generally not recommended. You can also call "ctest -V" or "ctest -VV" in the same directory where you're calling "make test" now, and it will run the full test suite and show you the output of all the tests. (-V == verbose, -VV == very verbose)
          – DLRdave
          Sep 1 '11 at 11:24












          Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
          – Landon
          Sep 2 '11 at 19:02




          Just FYI, I really appreciate the rapid response (and the one below as well). I've just been busy with school and haven't had time to test either of these. As soon as I do I will choose best answer appropriately. Just wanted to let you know I hadn't forgotten. :)
          – Landon
          Sep 2 '11 at 19:02













          12














          Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.






          share|improve this answer





















          • I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
            – Kurt Schwehr
            Nov 18 '12 at 19:54










          • Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
            – Sergei Nikulov
            Nov 19 '12 at 8:24










          • @KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
            – Sergei Nikulov
            Dec 3 '12 at 9:37
















          12














          Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.






          share|improve this answer





















          • I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
            – Kurt Schwehr
            Nov 18 '12 at 19:54










          • Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
            – Sergei Nikulov
            Nov 19 '12 at 8:24










          • @KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
            – Sergei Nikulov
            Dec 3 '12 at 9:37














          12












          12








          12






          Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.






          share|improve this answer












          Here the my example. I've made it as short guideline for my dev team. Perhaps you'll find it useful also.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Sep 1 '11 at 4:22









          Sergei NikulovSergei Nikulov

          4,2151730




          4,2151730












          • I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
            – Kurt Schwehr
            Nov 18 '12 at 19:54










          • Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
            – Sergei Nikulov
            Nov 19 '12 at 8:24










          • @KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
            – Sergei Nikulov
            Dec 3 '12 at 9:37


















          • I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
            – Kurt Schwehr
            Nov 18 '12 at 19:54










          • Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
            – Sergei Nikulov
            Nov 19 '12 at 8:24










          • @KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
            – Sergei Nikulov
            Dec 3 '12 at 9:37
















          I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
          – Kurt Schwehr
          Nov 18 '12 at 19:54




          I like that this example is simple. However, the current guidance from the gtest team is to include the gtest source with the package. Any examples of doing that around?
          – Kurt Schwehr
          Nov 18 '12 at 19:54












          Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
          – Sergei Nikulov
          Nov 19 '12 at 8:24




          Yes. I'm aware about this change. Will check it and soon and will update it accordingly.
          – Sergei Nikulov
          Nov 19 '12 at 8:24












          @KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
          – Sergei Nikulov
          Dec 3 '12 at 9:37




          @KurtSchwehr I've started implemented new way and eventually found solution here stackoverflow.com/questions/9689183/cmake-googletest . Will update as suggested in above answer.
          – Sergei Nikulov
          Dec 3 '12 at 9:37


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f7262370%2funit-test-output-project-structure-advice-cmake-google-test-framework%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

          Calculate evaluation metrics using cross_val_predict sklearn

          Insert data from modal to MySQL (multiple modal on website)