Enable doctrenderer (V8) gtest suites under CTest

[juliusknorr]

Summary

Migrates the three doctrenderer GoogleTest suites from legacy qmake .pro files to CMake targets registered with CTest, in one PR. Each gets a CMakeLists.txt modeled on the existing TestSMConverter reference and the shared add_core_gtest() helper.

Suite	Target	Define	Own main()?	GTEST_MAIN
test/json	doctrenderer_json_test	JSON_GOOGLE_TEST	compiled out under the define	yes
test/js_internal	doctrenderer_jsinternal_test	JS_INTERNAL_GOOGLE_TEST	compiled out under the define	yes
test/embed/internal/hash	doctrenderer_hash_test	none	none	yes

For json and js_internal, main.cpp guards its int main() behind #ifndef <SUITE>_GOOGLE_TEST — so with the define active there is no own main(), hence GTEST_MAIN. The hash suite has no main() and no google-test define, so it also uses GTEST_MAIN.

Each suite:

• guard-adds the existing doctrenderer shared library via if(NOT TARGET doctrenderer) add_subdirectory(...) endif();
• mirrors the .pro INCLUDEPATH (DesktopEditor/doctrenderer) via target_include_directories;
• mirrors DEFINES via target_compile_definitions;
• on Linux reproduces -Wl,-unresolved-symbols=ignore-in-shared-libs and -ldl via target_link_options / target_link_libraries.

All three are registered in the top-level CMakeLists.txt if(EO_BUILD_TESTS) block, and TESTING.md is updated (the three entries moved to Done with a V8-runtime note).

V8 runtime decision: registered normally (CI-gated)

These suites instantiate CJSContext (a V8 isolate) at test time, so they need a working V8 runtime. I investigated whether that is reliably satisfiable in CI and concluded yes, so the add_subdirectory lines are registered normally (not commented out):

• common.cmake builds the V8 monolith via build_3rdparty.py and populates V8_INSTALL_DIR; CI configures with -DVCPKG_MANIFEST_FEATURES=tests -DEO_BUILD_TESTS=ON and builds before ctest.
• The x64-linux V8 build (Common/3dParty/v8/.../nc-build.sh) sets v8_use_external_startup_data=false (startup snapshot is linked into the monolith, no external snapshot_blob.bin) and v8_enable_i18n_support=false (no external icudtl.dat). So CJSContext initializes with no external V8 runtime data files staged next to the binary.
• The doctrenderer shared library is already built in CI (the docbuilder app links it), so no new library provisioning is required.
• The suites build all their JS inline via runScript(...) and load no embedded-script or fixture files.

Build / verify note

cmake + ninja are present locally but there is no vcpkg toolchain (VCPKG_ROOT unset), so a full local build is not possible and I did not bootstrap vcpkg. The CMake wiring mirrors the proven TestSMConverter / TestEQNtoOOXML references; the PR's CI (configure with the tests feature + EO_BUILD_TESTS=ON, build, ctest --output-on-failure) is the gate.

Residual uncertainty

The V8 self-containment conclusion is read from the build flags rather than observed at runtime locally. If CI surfaces an unexpected external-data dependency, the fix would be to stage that data next to the test binaries (or point WORKING_DIRECTORY), not to change the test wiring.

https://claude.ai/code/session_01TJrhgZT4PwYaBKWiUCXmGg

---

Generated by Claude Code