Support find_package(Slint) from the build tree (FetchContent, no install)

[yuiseki]

What I would like

find_package(Slint) currently works only against an installed Slint.

When Slint is vendored into a C++ project via FetchContent (add_subdirectory), the Slint::Slint target is available, but find_package(Slint) does not resolve from the build tree.

I would like find_package(Slint) to work directly from the build tree too, so a consumer can keep one uniform find_package(Slint) + slint_target_sources() code path whether Slint is installed or vendored.

Why (use case)

I am building a C++ app that vendors both maplibre-native and Slint through FetchContent and wants a hermetic build with no dependency on a system-installed Slint (a system Slint on the build host was contaminated with unrelated Qt/ICU paths).

The clean way to consume Slint like everyone else is find_package(Slint), but today that forces an install step or a subproject-specific special case.

Being able to find_package(Slint) from the build tree removes that friction and keeps the build self-contained.

What is missing today

From a quick look, the build-tree side of the CMake packaging is wired for the install case only: the exported targets file is written relative to the top-level build dir (so it lands in the wrong place when Slint is a subproject), the generated SlintConfig.cmake uses install-prefix-relative paths, and SlintMacro.cmake is not placed next to a build-tree config.

So find_package(Slint) from the build tree either does not find the config or resolves to install paths that do not exist yet.

Offer

I have a small, working patch (that changes api/cpp/CMakeLists.txt only) that emits a build-tree package config with absolute paths, the built slint-compiler, and SlintMacro/SlintTargets alongside it, and I verified find_package(Slint) resolving from a FetchContent build tree with it.

The diff is here:

• master...yuiseki:slint:fix/cmake-build-tree-package

If this direction is welcome I am happy to open a PR, including a test that FetchContents Slint and calls find_package(Slint) from the build tree.

[ogoffart]

This looks good.

The CMAKE_BINARY_DIR -> CMAKE_CURRENT_BINARY_DIR fix is correct and worth having on its own.

On CMake 3.24+ there's a lighter option: FetchContent's find_package redirection (OVERRIDE_FIND_PACKAGE / dependency providers) gives the same uniform find_package(Slint) path without adding a build-tree config to Slint at all. We currently support CMake 3.21, but I'm open to bumping our minimum to 3.24, but that means updating our docs.