File: openvdb_cmd/vdb_tool/CMakeLists.txt, lines 98–108 on master:
if(OPENVDB_TOOL_USE_PDAL)
target_compile_definitions(vdb_tool_common INTERFACE "VDB_TOOL_USE_PDAL")
if(WIN32)
find_package(libdpal CONFIG REQUIRED) # <-- line 101
else()
find_package(PDAL REQUIRED)
endif()
message(STATUS "PDAL: ${PDAL_LIBRARIES} ${PDAL_INCLUDE_DIRS}")
target_link_libraries(vdb_tool_common INTERFACE ${PDAL_LIBRARIES})
target_include_directories(vdb_tool_common INTERFACE ${PDAL_INCLUDE_DIRS})
endif()
Problem: The Windows branch asks for a CMake package named libdpal — a transposition of libpdal. No such package exists, so on Windows OPENVDB_TOOL_USE_PDAL=ON (and therefore OPENVDB_TOOL_USE_ALL=ON) always fails at configure time with Could not find a package configuration file provided by "libdpal".
Fixing the spelling alone is not enough. The variables consumed afterwards — PDAL_LIBRARIES, PDAL_INCLUDE_DIRS — are set by PDAL's own PDALConfig.cmake, whose package name is PDAL on every
platform (PDAL's documented usage is find_package(PDAL REQUIRED CONFIG); the vcpkg port installs that same config). A libpdal package config would not define them either. The WIN32 special case appears to have no purpose.
Suggested fix: collapse the branch to a single find_package(PDAL CONFIG REQUIRED), or find_package(PDAL REQUIRED) matching the existing non-Windows line.
Introduced: f04f2f6 (2024-05-20, "Added feature to read points into vdb_tool using Point Data Abstraction Library (PDAL)"). Present in every release since, including v13.1.0.
Why unnoticed: CI never builds vdb_tool with PDAL on any platform (grep -ri pdal ci/ .github/workflows/ is empty), and no existing issue or PR mentions libdpal.
Severity: low — it blocks one optional feature on one platform, loudly, at configure time. No effect on the default build.
File: openvdb_cmd/vdb_tool/CMakeLists.txt, lines 98–108 on master:
if(OPENVDB_TOOL_USE_PDAL)
target_compile_definitions(vdb_tool_common INTERFACE "VDB_TOOL_USE_PDAL")
if(WIN32)
find_package(libdpal CONFIG REQUIRED) # <-- line 101
else()
find_package(PDAL REQUIRED)
endif()
message(STATUS "PDAL: ${PDAL_LIBRARIES} ${PDAL_INCLUDE_DIRS}")
target_link_libraries(vdb_tool_common INTERFACE ${PDAL_LIBRARIES})
target_include_directories(vdb_tool_common INTERFACE ${PDAL_INCLUDE_DIRS})
endif()
Problem: The Windows branch asks for a CMake package named libdpal — a transposition of libpdal. No such package exists, so on Windows OPENVDB_TOOL_USE_PDAL=ON (and therefore OPENVDB_TOOL_USE_ALL=ON) always fails at configure time with Could not find a package configuration file provided by "libdpal".
Fixing the spelling alone is not enough. The variables consumed afterwards — PDAL_LIBRARIES, PDAL_INCLUDE_DIRS — are set by PDAL's own PDALConfig.cmake, whose package name is PDAL on every
platform (PDAL's documented usage is find_package(PDAL REQUIRED CONFIG); the vcpkg port installs that same config). A libpdal package config would not define them either. The WIN32 special case appears to have no purpose.
Suggested fix: collapse the branch to a single find_package(PDAL CONFIG REQUIRED), or find_package(PDAL REQUIRED) matching the existing non-Windows line.
Introduced: f04f2f6 (2024-05-20, "Added feature to read points into vdb_tool using Point Data Abstraction Library (PDAL)"). Present in every release since, including v13.1.0.
Why unnoticed: CI never builds vdb_tool with PDAL on any platform (grep -ri pdal ci/ .github/workflows/ is empty), and no existing issue or PR mentions libdpal.
Severity: low — it blocks one optional feature on one platform, loudly, at configure time. No effect on the default build.