Modernize CDT++ as a regression oracle for causal-triangulations

[acgetchell]

Summary

Modernize CDT++ enough that it builds again and can serve as a bounded regression/comparison oracle for the Rust causal-triangulations implementation.

The goal is not to restart active C++ product development. The goal is to preserve the useful implementation lessons from the CGAL-based prototype, especially the causality-filtering construction path:

1. build a Delaunay/PL triangulation from labeled causal vertices;
2. classify cells by stored time labels;
3. find acausal or unclassified cells;
4. choose offending vertices;
5. remove those vertices through CGAL so the cavity is retriangulated;
6. repeat until the triangulation satisfies the causal foliation contract.

This is the design lineage now being tracked in causal-triangulations as acgetchell/causal-triangulations#192.

Scope

Keep the first pass deliberately small:

• restore a local build on one primary platform, preferably macOS or Ubuntu;
• update the minimum CMake/compiler expectations only as needed;
• run the existing test suite far enough to identify currently broken areas;
• preserve the fix_timevalues / check_timevalues / find_bad_vertex construction logic as a documented comparison point;
• add one README section explaining CDT++'s status as historical/experimental reference code, not the current supported implementation;
• document a small set of fixtures or commands that can be compared against causal-triangulations.

Non-goals for this issue:

• no full release process;
• no broad API redesign;
• no new physics functionality;
• no attempt to make CDT++ the primary implementation again;
• no package-manager migration unless vcpkg blocks the bounded build-restoration goal.

Package-Manager Recommendation

Start by staying with vcpkg.

Reasons:

• The repository already has vcpkg.json and CMake preset integration.
• The dependency stack is not just small header-only libraries: it includes CGAL, GMP/MPFR, Boost.Program_options, TBB, Eigen, fmt, spdlog, doctest, and support libraries.
• CGAL is header-only in modern releases, but its essential dependency story still includes GMP, MPFR, and Boost headers; CDT++ also uses compiled Boost.Program_options.
• vcpkg manifest mode gives each project an isolated vcpkg_installed tree and supports versioning/baselines, which is the right level of reproducibility for this archival/reference repo.

Concrete vcpkg cleanup candidates:

• add or refresh a builtin-baseline in vcpkg.json;
• remove stale CI references to Travis/AppVeyor unless they are still useful as documentation;
• simplify the CMake presets to one smoke-build preset and one test preset;
• document VCPKG_ROOT, CMAKE_TOOLCHAIN_FILE, and the single blessed configure/build/test command;
• keep optional viewer/Qt/demo paths disabled until the core test target builds.

Alternatives considered:

• Conan 2 is viable and more powerful for serious C++ package/binary workflows, but it would introduce profiles, generators, lockfiles, and recipe migration work before we know whether the code itself still builds.
• CPM.cmake/FetchContent is attractive for small modern CMake projects and header-only dependencies, but it is not a good first choice for the CGAL/GMP/MPFR/Boost/TBB stack.
• System package managers, Homebrew, apt, or Spack may be useful for one-off local/HPC experiments, but they are not the simplest cross-platform repo-level restoration path.

Acceptance Criteria

• A fresh checkout has one documented command path for configuring, building, and running tests.
• The package-manager decision is documented in the README or a short maintenance note.
• The build either succeeds or fails with a short, current list of concrete blockers.
• The causality-filtering Delaunay construction code is identified in documentation as the reason this repo remains useful as a reference.
• At least one fixture or test is named as a possible comparison against the Rust implementation.

[acgetchell]

vcpkg maintenance note

For the first modernization pass, do not migrate away from vcpkg, and do not treat a personal vcpkg checkout as project state.

Recommended model:

• Keep a normal user-local vcpkg checkout or installation, e.g. $HOME/src/vcpkg or $HOME/vcpkg.
• Keep $VCPKG_ROOT pointing at that checkout.
• Treat the checkout as replaceable tool/cache infrastructure, not as part of CDT++.
• Put reproducibility in this repository's vcpkg.json, especially a builtin-baseline.
• Update dependencies intentionally with vcpkg x-update-baseline, then review the resulting manifest diff.
• Update the vcpkg tool/registry checkout occasionally with git -C "$VCPKG_ROOT" pull followed by bootstrap, but do not require contributors to use Adam's exact local checkout.

Why this is better than keeping a bespoke vcpkg repo around:

• vcpkg manifest mode is designed for project-local dependency declarations and per-project vcpkg_installed trees.
• The builtin-baseline pins the registry baseline used for dependency resolution, so the repo records "what dependency universe did this build use?"
• The local vcpkg checkout becomes disposable. If it gets weird, reclone it.
• Binary caching can reduce rebuild pain without changing the dependency manager. On Unix-like systems, vcpkg defaults to $XDG_CACHE_HOME/vcpkg/archives or $HOME/.cache/vcpkg/archives, and CI can add a cloud/cache-backed binary cache later if restoration proves useful.

Documentation TODOs for this issue:

• Add a short "vcpkg maintenance" section to the README or a maintenance note.

• Add or refresh builtin-baseline in vcpkg.json.

• Document the one blessed local setup path:

  git clone https://github.com/microsoft/vcpkg "$HOME/vcpkg"
  "$HOME/vcpkg/bootstrap-vcpkg.sh"
  export VCPKG_ROOT="$HOME/vcpkg"

• Document the dependency refresh path separately:

  git -C "$VCPKG_ROOT" pull
  "$VCPKG_ROOT/bootstrap-vcpkg.sh"
  "$VCPKG_ROOT/vcpkg" x-update-baseline

This keeps the old C++ tooling burden bounded: vcpkg stays, but CDT++ owns only its manifest and baseline.