Optimize requires C++17 and CMake 3.21+. In a full Gecode source build, GECODE_ENABLE_OPTIMIZE defaults to OFF. Enable it explicitly; the native bridge also requires integer and search components. GECODE_OPTIMIZE_WITH_NATIVE defaults to ON when those native targets exist. For a native-only component:

cmake -S . -B build/native-optimize \
  -DGECODE_ENABLE_OPTIMIZE=ON -DGECODE_OPTIMIZE_WITH_HIGHS=OFF \
  -DGECODE_ENABLE_INT_VARS=ON -DGECODE_ENABLE_SEARCH=ON
cmake --build build/native-optimize --parallel 2

A standalone numerical build uses -S gecode/optimize and an installed HiGHS package, or GECODE_OPTIMIZE_HIGHS_SOURCE pointing to a separately obtained source checkout. The tested dependency is HiGHS 1.15.1 at commit 04024d701f79feb8e2f18bc3df0dffc04ef05088. CMake does not fetch it. A standalone build cannot enable the native bridge. With both backends disabled, model, checking, exchange and coordinator APIs remain available; solving returns Unsupported rather than a substitute implementation.

After installation, use one matching package discovery route:

find_package(Gecode CONFIG REQUIRED COMPONENTS optimize) # combined package
# Or: find_package(GecodeOptimize CONFIG REQUIRED)         # standalone
target_link_libraries(my_target PRIVATE Gecode::optimize)

Both expose Gecode::optimize and Gecode::gecodeoptimize aliases. For the C library use Gecode::optimize_c. A native-only component request does not require HiGHS. Compiled native libraries and generated configuration headers must match; do not mix different ABI/configuration or sanitizer cohorts.

The existing native documentation target uses Doxygen 1.17.0 or newer and uv for generated helper pages. These Optimize pages are part of that target even when the optional solver component is disabled. Documentation does not enable a backend. The repository's docs/solver-parity/README.md contains detailed commands and links to per-feature contracts.