[cgal] add eigen3/tbb/ceres/openmesh features, split qt-svg out of qt

[N'yoma Diamond (nyoma-diamond)]

This PR adds standalone opt-in features for several of CGAL's optional third-party libraries, and fixes the existing qt feature to only depend on what CGAL's Qt integration actually requires.

Closes #48042 (requests an eigen3 feature and points out qt is overspecified).
Closes #10736 (clarifies intent/expectation to properly enable CGAL's TBB support).

New/changed features:

Feature	What it adds	Notes
eigen3	eigen3	Previously only obtainable by enabling qt, which has nothing to do with Eigen3
qt	qtbase[widgets]	Dropped eigen3 (see above) and qtdeclarative (never referenced by CGAL's Qt6 GraphicsView. Verified by reading CGAL_SetupCGAL_Qt6Dependencies.cmake, which only ever touches OpenGL/OpenGLWidgets/Widgets, plus optional Svg)
qt-svg	qtsvg, requires qt	Split out because CGAL declares Svg via OPTIONAL_COMPONENTS, not as a hard requirement of Qt support
tbb	tbb	Enables CGAL::TBB_support for CGAL's parallel algorithms
ceres	ceres	Enables CGAL::Ceres_support, used in mesh-processing optimization (e.g. angle/area smoothing)
openmesh	openmesh	Enables CGAL::OpenMesh_support, an alternative mesh data structure usable with CGAL's BGL-based algorithms

usage now documents the exact CMake needed per feature, since CGAL never links any of these automatically. Every one of CGAL's optional third-party integrations is opt-in per-target by design, matching what CGAL's own example CMakeLists.txt files do.

Design choices / caveats

• Per-target opt-in, not auto-detection. [CGAL] Enable CGAL_LINKED_WITH_TBB #10736's original ask was for the port to auto-detect TBB and enable it if present. This wasn't implemented as literally requested: It would violate the maintainer guide's "ports must not be path dependent" rule. A port's installed output/behavior must not silently change based on what else happens to be installed. Explicit per-feature opt-in (as done here) keeps cgal's behavior deterministic regardless of install order, and matches CGAL's own upstream design: Every one of its roughly 15 CGAL_*_support.cmake modules (Eigen3, TBB, Ceres, OpenMesh, OpenCV, METIS, and GLPK, among others) is opt-in per-target via an explicit include() + target_link_libraries(), not auto-enabled.

• find_package(... CONFIG REQUIRED) in usage, not QUIET. CGAL's own examples use QUIET (no REQUIRED) because they need to configure across arbitrary environments where the optional dependency may or may not exist at all. That's the wrong pattern for usage's audience: If you've enabled cgal[tbb] (etc.) via vcpkg, the dependency is guaranteed to be installed, so a silent find_package failure only masks real misconfiguration (wrong triplet, broken toolchain file). CONFIG also avoids a real hazard, beyond simple correctness. CGAL bundles its own legacy FindTBB.cmake (a raw TBB_ROOT-based module predating oneTBB) on CMAKE_MODULE_PATH, and CMake tries Module mode before Config mode by default. Without CONFIG, a machine with stray TBB_ROOT/TBB_ARCH_PLATFORM env vars from an unrelated install could silently hijack discovery away from vcpkg's package. Verified all five (Eigen3Config.cmake, TBBConfig.cmake, CeresConfig.cmake, OpenMeshConfig.cmake, and Qt6Config.cmake) are actually installed by vcpkg's respective ports.

• CGAL_setup_CGAL_Qt6_dependencies() alone is not sufficient. It links CGAL::CGAL, CGAL::Qt6_moc_and_resources, and Qt6::OpenGLWidgets with the INTERFACE keyword, which (per CMake semantics) only propagates to further consumers of your target: It doesn't reach an executable's own link line. usage documents linking those three explicitly as well, confirmed by hitting LNK2001 unresolved external symbol ...GraphicsItem::metaObject without it.

• openmesh, ceres, tbb, eigen3, and qt/qt-svg were each individually built and run against real upstream CGAL examples (Polygon_mesh_processing/examples for TBB/Ceres, BGL/examples/BGL_OpenMesh for OpenMesh, Solver_interface/examples for Eigen3, and a TriangulationGraphicsItem/QGraphicsView program for Qt), confirming actual execution rather than a successful configure step alone. This caught both the INTERFACE-linkage issue above and confirmed vcpkg's ceres package sets the legacy uppercase CERES_FOUND variable that CGAL_Ceres_support.cmake checks for.

• METIS/GLPK/OSQP/OpenCV/ITK were investigated but not added in this PR. They follow the identical simple pattern, but I didn't build/run/verify them the same way, and some (ITK, OpenCV) are heavy dependencies. Happy to follow up separately if there's interest.

Checklist

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version, or no changes were necessary.
• Any fixed CI baseline and CI feature baseline entries are removed from that file, or no entries needed to be changed.
  • The existing cgal[qt]:arm64-linux=cascade entry is unrelated to this change and left as-is.
  • Added cgal[qt-svg]:arm64-linux=cascade. qtbase:arm64-linux=fail and qtsvg:arm64-linux=cascade already confirm the same cascade path, and qt-svg depends on both cgal[qt] and qtsvg directly.
• All patch files in the port are applied and succeed.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

[Billy O'Neal (BillyONeal)]

GPT 5.6 Sol reports:

• The license expression omits MIT, although the installed CGAL/Classification/ETHZ headers are covered by upstream's exact MIT text in Installation/LICENSE.RFL.

Would you consider nyoma-diamond#2 ?

[N'yoma Diamond (nyoma-diamond)]

Gladly :)

[Kai Pastor (dg0yt)]

CGAL is header-only, so all this does is pre-install the dependencies subject to features.

• The port always announces all features in usage regardless of actual configuration. Confusing.
• CGAL_<foo>_support.cmake seems to be installed regardless of the corresponding feature being enabled.

So basically it moves the port from "install the desired deps explicitly" to "install the features"? It would be useful if the user wouldn't need to know the deps. But OTOH users are still expected to manually do explicit find_package for the required deps because CGAL's CMake doesn't take care of it.

(No changes requested, just taking notes.)

[Billy O'Neal (BillyONeal)]

I think Kai Pastor (@dg0yt) makes some good points; N'yoma Diamond (@nyoma-diamond) can you respond? If downstream customers need to do this surgery themselves that seems a strong argument to me to not add features that just pass through dependencies.

[N'yoma Diamond (nyoma-diamond)]

Kai Pastor (@dg0yt) Billy O'Neal (@BillyONeal)

Very fair point. In that case to be honest if we're following the thought of not wanting downstream consumers to need to manage the machinery manually, I'd actually suggest going the reverse direction and removing the existing qt feature altogether and let consumers decide if/how to pull it in themselves.

If we kept the features, theoretically it may be possible to implement CMake scripts and/or apply patches to CGAL that would handle this surgery automatically, but I suspect that would be very clunky and potentially fragile. It also introduces the risk that a project with subprojects would end up forcibly including the optional features in all subprojects, even if only one needed them. E.g., suppose a project A which just needs base CGAL, with subprojects B and C, of which B also requires the Qt feature. If the port were to automatically configure all requested optional features to be enabled, then both A and C would also get them, even if they don't need it, which may introduce unnecessary bulk and build-time expense.

The primary reason I proposed the new features was to clean up the existing Qt feature and pull out Eigen. I just added the additional features while I was at it since they're pretty simple. Given the existing Qt feature already required manual surgery, I thought I'd stick to that existing methodology rather than try to uproot things.

The way I see it there are three potential approaches to take:

(A) Remove the qt feature altogether and disregard this proposal. Encourage downstream consumers to read CGAL's documentation for including optional third-party dependencies (could make note of this in usage?) and handle it themselves.

(B) Accept this proposal as-is with awareness that some manual intervention is still required for functional use. My hope is the updated usage file makes it clear enough that said intervention should be trivially intuitive.

(C) Inject explicit intervention to provide the optional third-party dependencies / features (or at least automatically include the corresponding helper scripts) alongside CGAL at all times if requested via vcpkg. This eliminates/reduces consumer labor, but requires circumnavigating CGAL's own suggestions for linking the third-party dependencies and is a much more complex methodology to implement and maintain (and also has the potential bulk issue mentioned above)

Personally I'm fine with any of these directions so long as the port's existing feature design (for qt) changes, as currently it satisfies none of the mentioned concerns.

Let me know your thoughts :)