Support consuming an external CppInterOp via CppInterOp_DIR

[guitargeek]

Providing CppInterOp_DIR selects external mode: cppjit consumes that CppInterOp install through find_package(CppInterOp) instead of building one with ExternalProject and bundling it into the wheel.

In this mode nothing is bundled: the library and include paths from the package config are baked into the wrapper as absolute paths, which works because cppinterop_paths() joins with std::filesystem's operator/, where an absolute right-hand side replaces the anchor. The clang major comes from CPPINTEROP_LLVM_VERSION_MAJOR in the config, so no LLVM is needed to build the wrapper itself; the LLVM discovery and version gate only run in the default bundled mode, since compatibility was already enforced when the external CppInterOp was built.

The mode is keyed to the explicitly provided CppInterOp_DIR variable, not to find_package succeeding through ambient search paths: otherwise a pip install inside e.g. a conda environment that happens to carry CppInterOp would silently produce a wheel that does not bundle its interpreter, making the wheel's composition depend on what the build environment has lying around.

An external CppInterOp carries no clang builtin headers, and clang's compiled-in resource dir default resolves relative to the library location, so CPPJIT_CLANG_RESOURCE_DIR should point at the resource dir matching the CppInterOp's clang. It is optional: when unset, CMake warns and the wrapper falls back to the existing runtime DetectResourceDir("clang-") probe, which works wherever a versioned clang is on PATH (e.g. conda environments). Distributions where it is not (e.g. NixOS) pass the resource dir explicitly.

The config file's CPPINTEROP_INSTALL_PREFIX is captured immediately after find_package, before the site-packages staging logic reuses that variable name.

Intended for distribution packaging (e.g. Nix), where CppInterOp is a separate package and duplicating its build in every consumer is wasted work (e.g. for the matrix of different LLVM and Python versions supported by Nix).

[vgvassilev]

I’d think providing just CPPINTEROP_DIR should make this use case work…

[guitargeek]

That's also possible. I have rewritten the logic such that the external CpInterOp path is triggered when the CppInterOp_DIR variable is set (not CPPINTEROP_DIR, to be consistent with CppInterOps CppInterOpConfig.cmake).

[vgvassilev]

I think we don't need the extra _cppjit_external_cppinterop but we can provide a HINT or an extra PATH and find_package will do the rest..

[guitargeek]

Right! I updated the PR.