Resolve "Windows: Linker errors with protobuf-generated code"

Summary

Related to #90 (closed)

• Moves grpc- and protobuf-generated code into a static library called caosdb_grpc
• Statically links all other targets to this static library.
• Change output folder of tests to the same as the shared libraries. (CMAKE_BINARY_DIR)
• Build tests for both Debug and Release build types (#92 (closed), not yet part of the pipeline)
• Adds make-like PowerShell script (make.ps1) for easily building on Windows.

Building libraries, cli clients and tests now completes without errors.

Focus

Point the reviewer to the core of the code change. Where should they start reading? What should they focus on (e.g. security, performance, maintainability, user-friendliness, compliance with the specs, finding more corner cases, concrete questions)?

Test Environment

Follow build instructions in the updated Install_develop.rst. Basically,

• Install Visual Studio 2022 with CMake
• Install Python Conan env
• Run .\make.ps1 all

Check List for the Author

Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab comments for the reviewer. They should guide the reviewer through the changes, explain your changes and also point out open questions. For further good practices have a look at our review guidelines

• All automated tests pass
• Reference related issues
• Up-to-date CHANGELOG.md (or not necessary)
• Up-to-date JSON schema (or not necessary)
• Appropriate user and developer documentation (or not necessary)
  • How do I use the software? Assume "stupid" users.
  • How do I develop or debug the software? Assume novice developers.
• Annotations in code (Gitlab comments)
  • Intent of new code
  • Problems with old code
  • Why this implementation?

Check List for the Reviewer

• I understand the intent of this MR
• All automated tests pass
• Up-to-date CHANGELOG.md (or not necessary)
• Appropriate user and developer documentation (or not necessary)
• The test environment setup works and the intended behavior is reproducible in the test environment
• In-code documentation and comments are up-to-date.
• Check: Are there specifications? Are they satisfied?

For further good practices have a look at our review guidelines.

test/CMakeLists.txt

@@ -67,7 +67,8 @@ foreach (i RANGE "${len_test_cases}")
     target_link_libraries(${test_case_name}
         PRIVATE GTest::gtest_main caosdb ccaosdb gtest::gtest caosdb_grpc)
     target_include_directories(${test_case_name}
-      PUBLIC ${CMAKE_CURRENT_BINARY_DIR}/include ${CMAKE_CURRENT_BINARY_DIR})
+      PUBLIC ${CMAKE_CURRENT_BINARY_DIR}/include ${CMAKE_CURRENT_BINARY_DIR})     
+     set_target_properties(${test_case_name} PROPERTIES RUNTIME_OUTPUT_DIRECTORY  "${CMAKE_BINARY_DIR}")
     if(_LINTING)
         message(STATUS "linting for tests: ${_CMAKE_CXX_INCLUDE_WHAT_YOU_USE}")
         set_target_properties(${test_case_name}
@@ -76,12 +77,15 @@ foreach (i RANGE "${len_test_cases}")
             CXX_INCLUDE_WHAT_YOU_USE "${_CMAKE_CXX_INCLUDE_WHAT_YOU_USE}")
     endif()
     gtest_discover_tests(${test_case_name}
-        WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}"
+        WORKING_DIRECTORY "${CMAKE_BINARY_DIR}"
         PROPERTIES
             LABELS "caosdb-cpplib-unit-tests"
         )
 endforeach ()
 
+message(STATUS "CMAKE_BINARY_DIR ${CMAKE_BINARY_DIR}")
+message(STATUS "CMAKE_CURRENT_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}")
+
 # copy test data to build dir
 set(TEST_DATA_DIR "${CMAKE_CURRENT_SOURCE_DIR}/test_data")
 configure_file(${CMAKE_CURRENT_SOURCE_DIR}/caosdb_test_utility.h.in