CMake requires data-file paths (LIBMAGIC_DATABASE_PATH, ...) as injected input instead of discovering them from the dependency

[andiwand]

Problem

When building with ODR_BUNDLE_ASSETS=ON (the default), CMakeLists.txt copies third-party data files into odrcore's data dir, e.g.:

file(COPY_FILE "${LIBMAGIC_DATABASE_PATH}" "${ODR_BUILD_ODR_DATA_PATH}/magic.mgc")

But LIBMAGIC_DATABASE_PATH (and the analogous FONTCONFIG_DATA_PATH, POPPLER_DATA_PATH, PDF2HTMLEX_DATA_PATH) is only consumed by CMake — it is never discovered by CMake. It has to be injected from outside via -DLIBMAGIC_DATABASE_PATH=....

Today only odrcore's own conanfile.py provides it, by reading the dependency's runenv (MAGIC) and forwarding it as a CMake variable:

tc.variables["LIBMAGIC_DATABASE_PATH"] = envvars.get("MAGIC")

This has two consequences:

1. Any other recipe that builds odrcore (e.g. the conan-odr-index recipe) must replicate this runenv→CMake bridging, or ODR_BUNDLE_ASSETS silently breaks: the variable is empty, so file(COPY_FILE "" ...) fails with cannot copy a directory.
2. It couples the CMake build to a conan runenv convention rather than to CMake package metadata.

Why find_package doesn't already provide it

find_package(libmagic) (via conan CMakeDeps) exposes the target, include dirs and lib dirs, and libmagic_PACKAGE_FOLDER_<CONFIG>, but not the data-file path — because the libmagic recipe advertises magic.mgc only via a runtime env var (self.runenv_info.define_path("MAGIC", .../res/magic.mgc)), and does not declare cpp_info.resdirs. So libmagic_RES_DIRS_<CONFIG> is empty and there is no CMake-native path to the file.

Suggested direction

Let odrcore's CMake discover the data files from the dependencies rather than requiring injected absolute paths, e.g.:

• Use libmagic_RES_DIRS (and equivalents) if the upstream packages are taught to declare cpp_info.resdirs, or
• Derive the path from libmagic_PACKAGE_FOLDER_<CONFIG> / the imported target location within CMakeLists.txt, so find_package(libmagic) is sufficient and no recipe needs to bridge runenv→CMake.

Workaround in the meantime

Consumers that provide the data paths at runtime (e.g. Android via odr::GlobalParams::set_libmagic_database_path) can build with ODR_BUNDLE_ASSETS=OFF and ship the data files themselves — which is what OpenDocument.droid now does (see opendocument-app/OpenDocument.droid#480).