feat(#519): Anim Slice B — vertex animation + Alembic (.abc) import #804
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,92 @@ | ||
| # Alembic (.abc) vertex-animation import — Anim epic Slice B (#519), sub-slice B2. | ||
| # | ||
| # Vendors Imath 3 + Alembic (both BSD-3-Clause) via FetchContent, statically, | ||
| # with every optional component OFF (no HDF5, Python, tests, binaries, install). | ||
| # Exposes an imported target `qtmesh_alembic` that the app links; the C++ side | ||
| # is #ifdef ENABLE_ALEMBIC-guarded so a build without this still compiles. | ||
| # | ||
| # Why build from source rather than find_package: Alembic + Imath system | ||
| # packages are absent or version-skewed across our three targets (macOS via | ||
| # brew, Ubuntu CI, Windows MinGW). FetchContent gives one reproducible version | ||
| # everywhere, matching how the project already vendors ONNX Runtime / libsodium | ||
| # / tinyexr. | ||
| # | ||
| # Dependency chain: Alembic FIND_PACKAGE(Imath) → we build Imath as a | ||
| # subproject first, point Imath_DIR at its generated build-tree config so | ||
| # Alembic's find_package(Imath CONFIG) resolves to the target we just built. | ||
|
|
||
| if(TARGET qtmesh_alembic) | ||
| return() | ||
| endif() | ||
|
|
||
| include(FetchContent) | ||
|
|
||
| set(QTMESH_IMATH_TAG "v3.1.12" CACHE STRING "Imath git tag") | ||
| set(QTMESH_ALEMBIC_TAG "1.8.8" CACHE STRING "Alembic git tag") | ||
|
|
||
| # ---- Imath --------------------------------------------------------------- | ||
| # Static, no tests/python. IMATH_INSTALL stays ON: Alembic's own | ||
| # INSTALL(EXPORT AlembicTargets) is unconditional and references Imath, so | ||
| # Imath MUST be in an export set too or CMake's generate step fails | ||
| # ("target Alembic requires target Imath that is not in any export set"). | ||
| # We never actually run `make install` from the app build, so an ON install | ||
| # rule is harmless — it just keeps the export sets consistent. | ||
| set(IMATH_INSTALL ON CACHE BOOL "" FORCE) | ||
| set(IMATH_INSTALL_PKG_CONFIG OFF CACHE BOOL "" FORCE) | ||
| set(PYTHON OFF CACHE BOOL "" FORCE) | ||
| set(BUILD_TESTING OFF CACHE BOOL "" FORCE) | ||
| set(BUILD_SHARED_LIBS OFF CACHE BOOL "" FORCE) | ||
|
|
||
| FetchContent_Declare( | ||
| qtmesh_imath | ||
| GIT_REPOSITORY https://github.com/AcademySoftwareFoundation/Imath.git | ||
| GIT_TAG ${QTMESH_IMATH_TAG} | ||
| GIT_SHALLOW TRUE | ||
| ) | ||
| FetchContent_MakeAvailable(qtmesh_imath) | ||
|
|
||
| # Alembic's find_package(Imath) resolves against a CONFIG. Imath-as-subproject | ||
| # writes its package config under the build dir; point find_package there. | ||
| if(NOT DEFINED Imath_DIR) | ||
| set(Imath_DIR "${qtmesh_imath_BINARY_DIR}/config" CACHE PATH "" FORCE) | ||
| endif() | ||
|
Comment on lines
+48
to
+52
There was a problem hiding this comment. 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🌐 Web query:
💡 Result: When using Imath 3.1.12 as a FetchContent subproject, the build-tree configuration files (including ImathConfig.cmake) are generated within the Imath build directory, specifically inside the directory defined by ${CMAKE_CURRENT_BINARY_DIR} [1]. In the Imath build system, the configuration files are managed in config/CMakeLists.txt [1]. The ImathConfig.cmake and associated version files are generated into the root of the Imath build directory (within that subproject's binary directory) using CMake's configure_package_config_file command [1]. Because FetchContent adds the project directly into the main build tree, you generally do not need to manually set Imath_DIR to locate the package [2][3]. Instead, you can simply call find_package(Imath CONFIG) in your downstream CMake code [3]. CMake will typically find the Imath targets exported within the current build session, allowing you to link against them using the Imath::Imath namespace [1][3]. If for any reason manual path resolution is required, it would point to the binary directory where the Imath subproject was configured [1]. Citations:
🏁 Script executed: #!/bin/bash
set -euo pipefail
printf 'Repo root: '; pwd
echo '--- files mentioning qtmesh_imath_BINARY_DIR / Imath_DIR / ImathConfig.cmake / configure_package_config_file ---'
rg -n --hidden --glob '!**/.git/**' 'qtmesh_imath_BINARY_DIR|Imath_DIR|ImathConfig\.cmake|configure_package_config_file|write_basic_package_version_file' .
echo '--- candidate files ---'
git ls-files | rg '(^|/)(Alembic\.cmake|CMakeLists\.txt|Imath|config/CMakeLists\.txt|config\.cmake)$'Repository: fernandotonon/QtMeshEditor Length of output: 984 🏁 Script executed: #!/bin/bash
set -euo pipefail
# Inspect the specific files that can establish the package-config output path.
for f in cmake/Alembic.cmake config/CMakeLists.txt; do
if [ -f "$f" ]; then
echo "=== $f ==="
wc -l "$f"
echo "--- outline ---"
ast-grep outline "$f" --view expanded || true
echo "--- excerpt ---"
cat -n "$f" | sed -n '1,220p'
echo
fi
doneRepository: fernandotonon/QtMeshEditor Length of output: 5125 🌐 Web query:
💡 Result: In Imath 3.1.12, the config/CMakeLists.txt file uses the CMake command configure_package_config_file to generate the ImathConfig.cmake file [1]. This command is part of the CMakePackageConfigHelpers module, which is essential for creating relocatable CMake package configuration files [2][3][4]. The usage in Imath 3.1.12 follows this standard pattern [1]: include(CMakePackageConfigHelpers) configure_package_config_file(${CMAKE_CURRENT_SOURCE_DIR}/ImathConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/ImathConfig.cmake INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/Imath) Key technical details regarding this configuration include: 1. Purpose of configure_package_config_file: Unlike the standard configure_file, this command is specifically designed for generating Config.cmake files [3][4]. It enables the created file to be relocatable by calculating path variables (like install directories) relative to the installation prefix, rather than using absolute build-time paths [3][4][5]. 2. CMAKE_CURRENT_BINARY_DIR: This variable is used as the output destination for the generated ImathConfig.cmake file [1]. Generating it here ensures that the file is created within the build tree, from where it can subsequently be installed to the final destination using an install command [1][5]. 3. INSTALL_DESTINATION: This mandatory argument specifies where the package configuration file will eventually be installed [3][5]. The command uses this path to correctly calculate relative paths within the generated configuration file, ensuring that when a user subsequently finds the package via find_package, the paths resolve correctly regardless of where the package was installed on their system [3][4]. 4. Workflow: After generating the file in the CMAKE_CURRENT_BINARY_DIR, the Imath build system uses the install command to copy the generated ImathConfig.cmake and associated version file (generated via write_basic_package_version_file) to the appropriate system directory (e.g., ${CMAKE_INSTALL_LIBDIR}/cmake/Imath) [1]. Citations:
🏁 Script executed: #!/bin/bash
set -euo pipefail
# Narrowly inspect any local copy of Imath sources if present.
fd -a 'config/CMakeLists.txt' .
fd -a 'ImathConfig.cmake.in' .
fd -a 'ImathConfigVersion.cmake.in' .Repository: fernandotonon/QtMeshEditor Length of output: 164 🌐 Web query:
💡 Result: In Imath v3.1.12, the configuration of the package's CMake files is managed within the config/CMakeLists.txt file [1][2]. The project utilizes the standard CMake command Citations:
🌐 Web query:
💡 Result: The function configure_package_config_file is a command provided by the CMakePackageConfigHelpers module in CMake. It is used to generate a package configuration file (typically named Config.cmake) for a project, which enables other projects to find and use your library via the find_package command [1]. In practice, CMAKE_CURRENT_BINARY_DIR is frequently used as the location to generate this configuration file before it is installed [1][2]. By generating the file in the binary directory, you ensure that the project can reference the generated configuration file (and associated version files) during both the build process and installation phase [1][2]. A typical usage pattern, as seen in projects like Imath, involves these steps: 1. Include the helper module: include(CMakePackageConfigHelpers) 2. Call the function: configure_package_config_file( ${CMAKE_CURRENT_SOURCE_DIR}/MyPackageConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/MyPackageConfig.cmake INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/MyPackage) This command configures the input template file (.cmake.in) by replacing variables with their current values and outputs the result to the specified file in CMAKE_CURRENT_BINARY_DIR, while setting up path variables to be relocatable based on the INSTALL_DESTINATION [1]. Citations:
Point 🤖 Prompt for AI Agents |
||
|
|
||
| # ---- Alembic ------------------------------------------------------------- | ||
| # Everything optional OFF: no HDF5 backend (we only read the modern Ogawa | ||
| # backend), no tests/binaries/python/prman/maya/arnold, static lib. | ||
| set(USE_HDF5 OFF CACHE BOOL "" FORCE) | ||
| set(USE_TESTS OFF CACHE BOOL "" FORCE) | ||
| set(USE_BINARIES OFF CACHE BOOL "" FORCE) | ||
| set(USE_EXAMPLES OFF CACHE BOOL "" FORCE) | ||
| set(USE_PYALEMBIC OFF CACHE BOOL "" FORCE) | ||
| set(USE_ARNOLD OFF CACHE BOOL "" FORCE) | ||
| set(USE_PRMAN OFF CACHE BOOL "" FORCE) | ||
| set(USE_MAYA OFF CACHE BOOL "" FORCE) | ||
| set(ALEMBIC_SHARED_LIBS OFF CACHE BOOL "" FORCE) | ||
| set(ALEMBIC_ILMBASE_LINK_STATIC ON CACHE BOOL "" FORCE) | ||
| set(ALEMBIC_LIB_INSTALL_DIR "lib" CACHE STRING "" FORCE) | ||
|
|
||
| FetchContent_Declare( | ||
| qtmesh_alembic | ||
| GIT_REPOSITORY https://github.com/alembic/alembic.git | ||
| GIT_TAG ${QTMESH_ALEMBIC_TAG} | ||
| GIT_SHALLOW TRUE | ||
| ) | ||
| FetchContent_MakeAvailable(qtmesh_alembic) | ||
|
|
||
| # Alembic's core library target is `Alembic` (with an `Alembic::Alembic` alias | ||
| # in recent versions). Wrap whichever exists behind our stable name so the app | ||
| # links `qtmesh_alembic` regardless. | ||
| if(TARGET Alembic::Alembic) | ||
| add_library(qtmesh_alembic INTERFACE) | ||
| target_link_libraries(qtmesh_alembic INTERFACE Alembic::Alembic Imath::Imath) | ||
| elseif(TARGET Alembic) | ||
| add_library(qtmesh_alembic INTERFACE) | ||
| target_link_libraries(qtmesh_alembic INTERFACE Alembic Imath::Imath) | ||
| # The plain `Alembic` target's public include dirs cover its own headers; | ||
| # Imath::Imath carries the Imath headers Alembic's public API exposes. | ||
| else() | ||
| message(FATAL_ERROR "Alembic.cmake: neither Alembic nor Alembic::Alembic target was created") | ||
| endif() | ||
|
|
||
| message(STATUS "Alembic ${QTMESH_ALEMBIC_TAG} + Imath ${QTMESH_IMATH_TAG} vendored (static)") | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When someone configures with
-DENABLE_ALEMBIC=ON, this branch executesinclude(.../cmake/Alembic.cmake), but that file is not present in the repo (checkedrg --files cmake). CMake will fail during configure before any guards can apply, so desktop/package builds that opt into the new feature cannot configure; either add the module in this commit or keep the option inert until B2.Useful? React with 👍 / 👎.