Sync cross-distribution Vinca package coverage - #41
Open
Tobias-Fischer wants to merge 159 commits into
Open
Conversation
Tobias-Fischer
force-pushed
the
codex/cross-distro-sync
branch
from
August 28, 2026 03:51
1e89074 to
d7cfa0b
Compare
- conda_build_config.yaml: add cmake 3.* workaround pin (avoids CMake 4 regression hitting ament packages on macOS/conda) - vinca.yaml: use conda-forge iceoryx 2.0.6 packages instead of ROS release copies (matches lyrical) - vinca.yaml: skip libpointmatcher (unreleased for rolling) so rtabmap can be added without breaking recipe generation - vinca.yaml: add rtabmap seed package (released for rolling) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…rtifacts check_patches_clean_apply.py builds throwaway "<pkg>-check-patches[-<platform>]" packages into the same output/<platform> directory to verify patches apply. Those never have a matching recipes/ entry, so build_gap_report.py was reporting every one of them as a false "built but no recipe" gap. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…inca_pinning.yaml, check_dependency_compat.py) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ROS2-Rolling API drift
Adds local ros2-libg2o (Qt6) and ros2-cv-bridge (OpenCV5) recipes to replace
Rolling's remote-only builds, which were still Qt5/OpenCV4-linked and
genuinely incompatible with the rest of this channel's pins (not just the
resolvo mutex-misattribution bug also worked around here for
ros2-web-video-server). These two unblock rtabmap and web-video-server.
Also fixes, across a mix of category-level (osx exclusions, endian shims,
Boost.ASIO API migration) and Rolling-specific issues:
- mavlink/libmavconn/mavros/mavros-extras (endian shim + GeographicLib link)
- udp-driver, robotiq-controllers, microstrain-inertial-driver (partial):
ament_target_dependencies() was removed from ROS2 Rolling's ament_cmake_target_dependencies
entirely; replaced with a local link_ament_dependencies() macro using each
dependency's exported <pkg>_TARGETS variable
- robotiq-controllers: hardware_interface::LoanedCommandInterface::get_value()
replaced by get_optional<T>() in ros2_control's realtime-safety rework
- turtle-tf2-cpp, imu-transformer, web-video-server: tf2_ros/image_transport
APIs migrated from raw Node* / multi-arg interface calls to a single
NodeInterfaces bundle constructed from a Node reference
- vision-msgs-rviz-plugins: Qt5->Qt6 (find_package, qt6_wrap_cpp, explicit
Qt6::Core/Widgets + rviz_default_plugins linking) and the rviz_common
Display::update() float->std::chrono::nanoseconds signature change
- nlohmann-json-schema-validator-vendor: CMAKE_POLICY_VERSION_MINIMUM=3.5
for its ExternalProject_Add'd vendored source (CMake<3.5 removed)
- ublox-dgnss-node: --allow-multiple-definition linker flag unsupported on
macOS ld (progress fix; a real duplicate-symbol ODR issue remains)
- rmf-building-map-tools: numpy>=2.0 removed 2D-vector np.cross() support,
used by is_in_lift() -- replaced with the direct scalar cross-product
formula. Unblocks the whole downstream rmf-demos-maps chain.
- rmf-traffic: missing #include <cassert> across 11 vendored FCL headers +
1 own source file; missing Eigen3::Eigen link (was relying on a
build-path-relative ${EIGEN3_INCLUDE_DIRS} variable baked into the
installed target, breaking downstream consumers)
- rmf-traffic-ros2: custom FindLibUUID.cmake unconditionally required a
standalone libuuid (Linux-only; macOS provides uuid/uuid.h natively, no
separate library) -- also missing Eigen3::Eigen link
- rmf-websocket: Boost 1.90 no longer ships a boost_system CMake config
(header-only now); dropped the component + Boost::system linkage
- mujoco_3d_lidar/mujoco_ros2_control_plugins excluded on osx (no prebuilt
MuJoCo binary for macOS, matching the same exclusion already used for
mujoco_ros2_control/_demos)
- ros2-distro-mutex rebuilt at 0.20.0/build 26 to match vinca.yaml's already
-bumped run_constraints (vtk 9.7.0), which had never actually been
republished
ros-rolling went from ~150 missing packages (of 311 recipes) to 12 still
blocked, each a genuinely deep out-of-scope issue for tonight: avt-vimba-camera
and rclc-examples need real rclcpp/image_transport/rcl API ports;
microstrain-inertial-driver needs further NodeInterfaces + tf2/LinearMath
porting; ublox-dgnss(-node) has a real duplicate-symbol ODR bug beyond the
linker-flag guard; the rmf-websocket chain (rmf-websocket, rmf-task-ros2,
rmf-fleet-adapter(-python), rmf-reservation-node, rmf-visualization-floorplans/
-schedule) is blocked on websocketpp itself using removed Boost.ASIO APIs
(io_service) -- a third-party dependency incompatibility, not this repo's
source.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…les/rmf_fleet_adapter/rmf_visualization_floorplans API drift), exclude avt_vimba_camera on osx - ublox-dgnss-node: the --allow-multiple-definition linker flag guard alone wasn't sufficient -- the actual duplicate symbols (ubxKeyCfgItemMap, storage_size_bytes, operator<(ubx_key_id_t), get_polled_frame) are plain non-inline definitions in headers included by multiple translation units, a genuine ODR violation Linux's ld tolerates and Apple's correctly rejects. Mark them `inline` instead of relying on the linker flag. - rclc_examples: rcl_timer_callback_t gained a third (uintptr_t) parameter on Rolling; updated all 9 example timer callbacks across 6 files. - rmf_fleet_adapter: malloc_trim() is glibc-only, guarded with #if defined(__linux__); missing <algorithm>/<unordered_set> includes (9 files); two int64_t/size_t-vs-long/long-long template deduction mismatches in std::max() calls, where the distinct-on-macOS types (uint64_t is `long long` there, not `long`/`size_t` as on Linux) fail to unify; three ROS-message std::vector<uint64_t> fields passed where FleetUpdateHandle expects std::vector<std::size_t> (distinct types on macOS, not just width) -- construct an explicit converting copy instead. - rmf_visualization_floorplans: cv::Mat's std::vector<uchar> constructor doesn't accept rosidl's message-array Buffer<uchar,allocator<uchar>> wrapper type directly -- copy through an explicit std::vector first. - rmf_visualization_schedule: pinned openssl >=3.6.4 (overriding, not additive to, this repo's openssl 3.5.* variant) -- resolvo otherwise falls back to older ros2-cyclonedds/ros2-fastdds builds whose newest builds need it, hitting the already-documented mutex-misattribution bug. - avt_vimba_camera: Allied Vision only ships prebuilt Vimba SDK binaries (libVimbaC/libVimbaCPP) for Linux (x86_64/arm) -- confirmed no source fix is possible (rclcpp/image_transport API-migration patches got it to actually reach the link step, where it fails on ELF .so files built for the wrong OS entirely). Excluded on osx via vinca.yaml, matching the existing mujoco_vendor precedent. ros-rolling now builds all 311 recipes (previously ~150 missing) on osx-arm64. Two dependencies needed real fixes that don't belong in this repo: rmf_websocket (patched here for its own source's rclcpp::Node NodeInterfaces migration and Boost 1.90 boost_system removal) depends on conda-forge's websocketpp package, whose bundled Asio transport code uses boost::asio APIs (io_service et al.) removed in Boost >=1.87 -- reported upstream as a conda-forge/websocketpp-feedstock PR rather than patched locally in this repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ervice) websocketpp 0.8.2 calls boost::asio::io_service, which Boost 1.90 removed. Rather than patch websocketpp itself, define ASIO_STANDALONE and pin the standalone asio host/run dep to ==1.29.0 (the newest conda-forge build that still ships io_service.hpp), matching the fix RoboStack/ros-lyrical#41 already validated. Also opened conda-forge/websocketpp-feedstock#8 upstream for the same Boost.Asio compatibility gap, for consumers not using ASIO_STANDALONE. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…parity rolling's package count (155 unique / ~304 recipes) lags far behind humble (1105) and jazzy (1004) despite near-identical explicit seed counts. Root cause: robostack.yaml (rosdep-key -> conda-forge package mapping) is missing 29 entries that humble already has, so vinca's dependency expansion silently drops those transitive deps instead of erroring. Ported the missing entries from humble/robostack.yaml (adapting qml-module-qtquick-extras to rolling's Qt6 baseline). Also added 12 genuinely-missing top-level seeds found by diffing packages_select_by_deps against humble/jazzy: ntrip_client, rqt_image_overlay, and the full yasmin_* family (yasmin, yasmin_cli, yasmin_demos, yasmin_editor, yasmin_factory, yasmin_msgs, yasmin_pcl, yasmin_plugins_manager, yasmin_ros, yasmin_viewer), all verified present in rolling's rosdistro_snapshot.yaml. Fixed an unrelated pre-existing duplicate vision_msgs_rviz_plugins line while in the area. Added a comment separator before the linux-and-not-aarch64 webots_ros2/ zed_msgs block: vinca-sort-vinca-lists pools then-items across adjacent if-blocks that aren't separated by a comment, which would otherwise bleed webots_ros2 into the wrong platform scope on the next sort. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rqt_image_overlay hard-depends on ros_image_to_qimage, which has a repo entry in rolling's rosdistro index but no released version at all -- a genuine upstream gap, not a robostack.yaml mapping issue. Selecting it crashes vinca's dependency walk with "Package 'ros_image_to_qimage' ... has no version set". Drop it from the seed list until upstream tags a release. Also move two previously-hand-edited recipe.yaml overrides into patch/dependencies.yaml so they survive `vinca -m` regeneration instead of needing to be reapplied by hand every time: - rmf_fleet_adapter_python: add pybind11_json to host (used for nlohmann::json<->pybind11 conversions, missing from package.xml) - rmf_visualization_schedule: bump openssl to >=3.6.4 in host/run Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ng channel Bare "-c robostack-rolling" resolves to https://conda.anaconda.org/robostack-rolling/ by default, which has zero packages -- rolling publishes to https://repo.prefix.dev/robostack-rolling instead (already used correctly by the `build` and `build-one` tasks, and by `upload`'s own target). Every fresh package build against this task failed with "No candidates were found for ros2-ament-cmake *" (or whatever core dependency the solver happened to name first) since the real channel was never actually being searched. Match the other two build tasks' channel argument. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…n osx
Five independent macOS-specific build failures fixed, verified with
individual rebuilds against the current recipe set:
- urg_node: urg_c_wrapper.cpp calls read()/write() without <unistd.h>.
- microstrain_inertial_driver: tf2/LinearMath/*.h headers no longer exist
(only .hpp now); two make_shared<tf2_ros::{Static,}TransformBroadcaster>
calls passed a Node* where the NodeInterfaces bundle needs a reference.
- motion_capture_tracking: same NodeInterfaces bundle issue, one call site
(tf2_ros::TransformBroadcaster tfbroadcaster(node) -> (*node)).
- realsense2_camera: upstream CMakeLists.txt guards Linux-only GNU-ld
hardening flags (-z noexecstack/relro/now) with if(UNIX OR APPLE) --
APPLE also sets UNIX, so these ELF-only flags leaked onto the Apple
linker, which rejects -z outright ("ld: unknown option: -z").
- rmw_stats_shim: same category of bug, gating -Wl,--no-undefined (a GNU
ld long option) on "Clang" without excluding Apple's clang+ld64 pairing.
Also move mujoco_ros2_control(_demos) into the existing osx-exclusion
block (packages_select_by_deps, not packages_skip_by_deps, since these
are explicitly-selected top-level seeds and skip_by_deps only prunes
transitive expansion): mujoco_ros2_control hard-depends on
mujoco_ros2_control_plugins, which is already macOS-excluded because
mujoco_vendor has no prebuilt MuJoCo binary there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
pcl_conversions's remote build at the current build_number (25) was published against vtk-base 9.6.2.*, which conda-forge no longer carries -- this repo's mutex run_constraints now pin vtk 9.7.0.*. Bump its build_number override to 26 so skip_existing stops matching that stale remote build, forcing a fresh local build against the current pins. Separately, discovered that ~/.condarc's channel_priority: strict (or rattler-build's own default) causes spurious "no candidates" failures whenever the local output/ channel happens to carry ANY build of a package name (here: ros2-distro-mutex, present locally at build 26 from earlier work) -- strict priority then refuses ALL other-channel builds of that name, even ones a completely unrelated dependency needs at an older, perfectly valid version. This bit pcl_conversions's own test dependencies (which pull in most of the ROS2 core stack) and would bite any future build in the same situation, including the sanctioned `build`/`build-one`/`build_continue_on_failure` tasks, since the test phase always implicitly adds output/ as a channel to install the just-built package. Add --channel-priority disabled to all three. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ces API package.xml's <depend>cartographer</depend> resolves to the REAL released ros2-cartographer ROS package, but this repo's own add_host ALSO pulls in the conda-forge cartographer C++ library directly for the same name -- vinca doesn't dedupe these, so both ended up in host/run with conflicting lua pins (conda-forge cartographer wants lua 5.4.8, ros2-cartographer wants lua 5.5.0), making the recipe unsolvable. Drop the ROS-released one via remove_host/remove_run; the conda-forge add_host is what's actually meant to satisfy this dependency (same generate_dummy_package_with_run_deps duplicate-registration pattern as the pinocchio/hpp_fcl case documented elsewhere in this repo's history). Once that resolved, hit the by-now-familiar Rolling NodeInterfaces bundle API drift in cartographer_ros's own source: three tf2_ros construction call sites (node.cpp's TransformBroadcaster, node_main.cpp and offline_node.cpp's tf2_ros::Buffer, offline_node.cpp's StaticTransformBroadcaster) passed a raw Node*/shared_ptr<Node> where the bundle needs a reference -- add the missing dereferences. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…em_modes_msgs seed rosgraph_monitor, rviz_2d_overlay_plugins, sick_safetyscanners_base, spacenav, system_modes, trac_ik, and zed_msgs were all gated under if: linux (or, for zed_msgs, linux and not aarch64) in this repo's vinca.yaml despite jazzy already building every one of them on osx (its own vinca.yaml selects them under "not win"/"not linux"). Moved them into the not-wasm32-and-not-win block instead of duplicating them, and added a comment separator so vinca-sort-vinca-lists' known adjacent-if-block-merging bug doesn't scramble the boundary on the next sort (see build_feedback.md's vinca-sort-vinca-lists entry, and RoboStack/vinca#152 for the upstream fix). Also added system_modes_msgs as an explicit seed -- system_modes depends on it but it wasn't reachable any other way for this distro. Each of the 7 was individually verified via rebuild before being kept in this platform-loosened state; three needed additional fixes to actually build once genuinely attempted for the first time on macOS: - rosgraph_monitor: same "-Wl,--no-undefined is GNU-ld-only" pattern already fixed for rmw_stats_shim this session. - system_modes: the already-documented Rolling-wide ament_target_dependencies() removal (see build_feedback.md), fixed with the same local link_ament_dependencies() macro pattern. - sick_safetyscanners_base: the largest fix of the three -- Boost.ASIO API removals across 8 files: find_package(Boost COMPONENTS system) dropped (header-only now, matches the rtabmap/web-video-server/ cartographer_ros pattern), boost::asio::io_service -> io_context, io_service::work -> executor_work_guard<io_context::executor_type> (constructed via make_work_guard), boost::asio::deadline_timer -> explicit boost::asio::basic_deadline_timer<boost::posix_time::ptime> (the plain deadline_timer typedef is gated behind a macro this Boost build doesn't define, but the underlying template is still present and just deprecated-not-removed), address_v4::from_string -> make_address_v4, address_v4::to_ulong -> to_uint, plus two missing <boost/date_time/posix_time/posix_time_types.hpp> includes that used to arrive transitively via the now-gated deadline_timer.hpp. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Completeness fix found by a full key-diff sweep (not just the earlier targeted one): konsole, libblosc-dev, libopenexr-dev, libopenvdb-dev, python3-textual, python3-torchvision(-pip), python3-ultralytics-pip. None of these are currently referenced by any package reachable in rolling's selected set (verified against a fresh vinca -m dependency walk), so this has no effect on the current recipe count -- it's purely to keep robostack.yaml in sync in case a future seed addition needs one of them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
linux-64: ros2-lttngpy fails CMake configure ("package lttng-ctl not
found") -- conda-forge only packages lttng-ust, not the separate
lttng-ctl control library, so this can never be satisfied by any
robostack.yaml mapping. lttngpy's own CMakeLists.txt already has a
DISABLED_DEFAULT option that's ON for WIN32/APPLE/ANDROID/BSD and OFF
(requiring lttng-ctl) everywhere else -- patch it to always be ON,
matching ros-jazzy's own lttngpy patch, which hit and fixed the exact
same issue.
linux-aarch64: ros2-rmf-traffic fails to compile with GCC ("'uint64_t'
does not name a type", cascading into ~15 further errors in the same
translation unit) -- GCC 15's leaner libstdc++ headers no longer
transitively provide <cstdint> the way clang/libc++ does, so this only
surfaced on Linux, never during this session's osx-arm64 testing.
Added the missing #include <cstdint> to all 11 first-party rmf_traffic
files that use fixed-width integer types without including it
directly.
win-64: `pixi run check-patches` fails on two unrelated, pre-existing
(not touched this session) patch-staleness issues from upstream source
drift, not a toolchain migration:
- ouster_ros's .win.patch is now fully redundant -- current upstream
CMakeLists.txt already has the exact MSVC/WIN32 compile-options and
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS handling the patch was adding.
Deleted the now-obsolete patch file entirely.
- plotjuggler's .win.patch's second hunk (inserting ${QT_LINK_LIBRARIES}
into `target_link_libraries(plotjuggler_base ...)`) no longer applies
-- upstream restructured plotjuggler_base's CMake target entirely
(no `${QT_LINK_LIBRARIES}` reference left near it at all). Removed
just that one obsolete hunk; the patch's other hunks (XCB linking,
QT_LINK_LIBRARIES trimming, protobuf API migration) still apply
cleanly and are untouched.
None of these three packages were built/tested locally against
linux-64/linux-aarch64/win-64 targets (no such environment available
here) -- fixes are based on direct source inspection (jazzy's proven
lttngpy patch, GCC's own documented header-pruning changes, and diffing
current upstream source against each patch's expected context).
osx-arm64 regression-tested for lttngpy and rmf_traffic; ouster_ros and
plotjuggler are skip-existing on osx-arm64 (already published at the
current build number) so could not be locally re-verified there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…in patch PR #41's own CI run surfaced 3 more real issues past the first round of fixes: - osx-arm64/osx-64: "pcl 1.15.1 would require vtk-base >=9.4.2 ... ros2-distro-mutex 0.20.0 would constrain vtk 9.6.2, conflicts" -- the exact channel-priority-strict symptom already fixed in pixi.toml's build/build-one/build_continue_on_failure tasks earlier this session, except testpr.yml's "Build recipes" step calls `pixi run rattler-build build ...` directly with its OWN hardcoded args written in the YAML, never going through those pixi.toml tasks at all. Added --channel-priority disabled to the workflow step itself. - linux-64: past lttngpy, hit the same GCC15/leaner-libstdc++ missing-<cstdint> pattern as rmf_traffic, this time in rmf_task (14 first-party files using uint32_t/uint64_t directly without including it). Same fix, same pattern -- these two rmf_* packages evidently share the same coding style/vintage. - win-64: past the first plotjuggler.win.patch hunk, check-patches hit a SECOND stale hunk in the same file (ParserProtobuf/CMakeLists.txt's Protobuf detection) -- also fully obsolete, upstream rewrote Protobuf detection entirely via `if(TARGET protobuf::libprotobuf)` checks (verified Protobuf_LIBS, the variable this hunk sets, isn't referenced anywhere in the current file at all). Removed. Two more hunks in this same win.patch (error_collectors.cpp/.h) may or may not still apply under rattler-build's own (more lenient than git apply/GNU patch) patcher -- left alone pending real CI confirmation rather than guessing further, per this session's own established lesson that rattler-build's patcher tolerates things git apply/patch reject. rmf_task regression-tested clean on osx-arm64. testpr.yml and the plotjuggler win-patch fix can only be verified by real CI (no local Linux/Windows environment, and osx doesn't exercise the .win.patch variant at all). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ler win patch rmf_visualization_schedule uses websocketpp::config::asio directly and hits the same io_service-removed-by-Boost-1.90 issue already fixed for rmf_websocket: define ASIO_STANDALONE and pin asio ==1.29.0 (the newest build that still ships io_service.hpp). Verified building clean on osx-arm64. Also remove the error_collectors.cpp/.h hunks from ros-rolling-plotjuggler.win.patch: upstream plotjuggler now guards AddError/AddWarning vs RecordError/RecordWarning behind GOOGLE_PROTOBUF_VERSION, so the old hunk no longer matches and was failing win-64's check-patches. Confirmed obsolete via direct inspection of the pinned release tag's source. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…os::Buffer vinca.yaml's mutex_package.build_number was bumped to 26 (vtk 9.7.0.* instead of 9.6.2.*) in an earlier commit, but should_skip_mutex_package only compares against pkg_additional_info.yaml's per-package override (falling back to the top-level build_number: 25 default). Without an override entry here, it still matched the stale remote ros2-distro-mutex 0.20.0 rolling_25 build and skipped generating a fresh recipe entirely -- so every package needing pcl (which carries a soft vtk run_constraint via the mutex) resolved against the old vtk 9.6.2 constraint and failed to solve against the now-vtk-9.7.0-only pcl builds on conda-forge. Adding the distro_mutex override forces vinca to generate and build a fresh local rolling_26 mutex package instead. Verified end-to-end on osx-arm64: built the fresh mutex, then rebuilt ros2-pcl-conversions against it successfully. Also add a missing #include <tf2_ros/buffer.hpp> (and .h fallback) to septentrio_gnss_driver: geometry2's transform_listener.hpp only pulls in tf2/buffer_core.hpp, not tf2_ros/buffer.hpp, so tf2_ros::Buffer was never declared. Confirmed against ros2/geometry2's rolling branch source and verified the patch applies cleanly via rattler-build's own patcher. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Upstream's CMakeLists.txt selects an EXACT Python version per $ENV{ROS_DISTRO},
matching whatever Python Ubuntu ships for that distro's release (3.12 for
rolling). conda-forge's Python floats independently and is currently pinned
to 3.14 here, so the EXACT match fails against conda's Python and CMake
falls back to searching the system Python instead, finding Ubuntu's
/usr/include/python3.12 headers (incomplete without python3-dev installed,
missing the Debian multiarch pyconfig.h) rather than $PREFIX's actual
Python 3.14. Replace the whole distro-keyed EXACT-version chain with a
plain `find_package(Python 3 REQUIRED COMPONENTS Development)`, so it just
resolves to whatever Python is active in the build environment. Verified
via check_patches_clean_apply.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…20 concepts Second, unrelated failure in the same package after the tf2_ros::Buffer fix: the top-level CMakeLists.txt unconditionally does add_compile_options(-std=c++17), which lands after ament's own default -std=gnu++20 on the compile command line -- the last -std= flag wins, so every translation unit compiles as C++17. That breaks class_loader's interface_traits.hpp, which now uses C++20 concepts (requires/concept) and std::ranges, on rolling's current rclcpp_components. Drop the override and let ament's own C++ standard apply. Verified via check_patches_clean_apply.py. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MSVC doesn't update the __cplusplus macro to reflect the actual C++ standard in use unless /Zc:__cplusplus is passed, so websocketpp's common/cpp11.hpp __cplusplus >= 201103L feature-detection always fails there, falling back to boost::is_same/boost::aligned_storage -- which recent Boost versions no longer provide (C2039/C2873 in websocketpp/common/type_traits.hpp). Adding the flag lets websocketpp correctly detect C++11 and use std:: type traits instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rmf_websocket.dll built fine but produced no companion .lib (no explicit dllexport annotations, and only 3 source files so the 65535-object import-lib limit that bit rmf_traffic_ros2 isn't a concern here), so example_client failed with LNK1181. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Switching rmf_traffic_ros2's PROJ link from PkgConfig::PROJ to PROJ::proj (71e7c44) made it a PUBLIC dependency that CMake now propagates into rmf_traffic_ros2's exported Config.cmake -- but PROJ was never added to ament_export_dependencies(), so the generated config never calls find_dependency(PROJ). Any downstream consumer (rmf_task_ros2 is the first to hit it) then fails to configure with "target PROJ::proj ... was not found". Added a WIN32-only ament_export_dependencies(PROJ) call. Also bumps rmf_traffic_ros2's build_number: build_25 was already published (compiles and packages cleanly) from before this fix existed, so skip_existing would otherwise keep serving that stale config to every downstream package. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ament_export_dependencies(PROJ) didn't actually fix the downstream consumer breakage: rmf_task_ros2's own pkg_check_modules(PROJ ...) call sets PROJ_FOUND=TRUE as a side effect before find_package( rmf_traffic_ros2) runs, so the auto-generated find_dependency(PROJ) guard silently no-ops and PROJ::proj never actually gets created in that scope. PROJ is only used in one internal .cpp file (convert_Graph.cpp), never in any installed public header, so there's no reason for it to be part of rmf_traffic_ros2's public link interface at all -- made it PRIVATE instead (matching the existing PRIVATE pattern already used for LibUUID/rpcrt4 in this same file), which sidesteps the whole propagation problem: consumers no longer need to know PROJ exists. Bumps build_number again since build_26 (the ament_export_dependencies attempt) was already published and didn't fix the issue. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same class of bug as the PROJ propagation issue, but for two of the message-package aggregate targets used on Windows (LNK1170 fix, ff4fb75): they're PUBLIC in rmf_traffic_ros2's link interface but were never in ament_export_dependencies() (missing even in the original upstream list, harmless there since non-Windows links via raw _LIBRARIES path lists that don't need find_dependency). Any downstream consumer's own find_package(rmf_traffic_ros2) now needs these targets to exist -- rmf_task_ros2 is the first to hit "target rmf_building_map_msgs::rmf_building_map_msgs ... was not found". Added both to a WIN32-only ament_export_dependencies() call. Unlike the PROJ case, no known variable-collision risk here since rmf_task_ros2 doesn't independently probe for these packages itself. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same issue and fix as rmf_traffic_ros2 hit earlier: \${rmf_task_msgs_LIBRARIES}
and \${rclcpp_LIBRARIES} each recursively re-append their own
dependencies' _LIBRARIES as plain strings with no deduplication,
overflowing link.exe's response-file line limit. Switched to the
rmf_task_msgs::rmf_task_msgs / rclcpp::rclcpp targets (WIN32-only).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Predictable gap in the selective-export scheme from the LNK1189 fix: only symbols needed by rmf_traffic_ros2's own executables were annotated. rmf_task_ros2 needs several of Time.hpp's convert()/ to_ros2() overloads (LNK2019 on rmf_traffic_ros2::convert for builtin_interfaces::msg::Time / rclcpp::Duration conversions). Exported the whole header (6 small conversion functions) rather than chasing individual overloads one at a time across future consumers. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vinca's add_package_name_variants() (vinca/utils.py) cross-links patch-file name-prefix variants (X <-> ros-X <-> ros2-X <-> ros-<distro>-X) via dict.setdefault(), a no-op once a prefix already has its own entry. If a package has a plain patch under one prefix and a platform-specific patch under a different prefix, the platform-specific one is silently never wired into any recipe -- no error, no warning. This exact bug orphaned jazzy's ros-jazzy-sick-scan-xd.osx.patch for months. Ported check_orphaned_platform_patches.py verbatim from RoboStack/ros-humble@765bf707 (identical script across distros, only needs ros_distro: from vinca.yaml) and wired it into `pixi run check-patches` as a new check-orphaned-patches task dependency, so it runs on every PR. Currently clean: no orphaned patches found on rolling. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rmf_task_ros2.dll built fine but produced no companion .lib (no explicit dllexport annotations, and only 5 source files so the 65535-object import-lib limit isn't a concern here), so rmf_task_dispatcher and rmf_bidder_node failed with LNK1181. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same _USE_MATH_DEFINES pattern hit repeatedly this session -- MSVC only defines M_PI when this macro is set before <cmath>/<math.h> is first included, and rmf_traffic's installed agv/Interpolate.hpp uses it unconditionally. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rmf_task_sequence.dll built fine but produced no companion .lib (no explicit dllexport annotations), so test_rmf_task_sequence failed with LNK1181. This also cascaded into rmf_fleet_adapter's configure step failing to find_package(rmf_task_sequence), since the package was never successfully published. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A stale win-64 build_25 was already published (predating the WINDOWS_EXPORT_ALL_SYMBOLS fix), so skip_existing kept reusing it -- which cascades into rmf_fleet_adapter failing to find_package( rmf_task_sequence) since that stale build's .dll has no import .lib. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same _USE_MATH_DEFINES pattern hit repeatedly this session -- M_PI is used unconditionally in rmf_traffic/rmf_utils's installed headers plus this package's own RobotContext.hpp/EasyFullControl.cpp. A large number of the reported errors in EasyFullControl.cpp are cascading parser-desync noise stemming from the M_PI failures a few lines earlier in the same file, not independent bugs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Three confirmed win-64 failures from the same round, bundled together:
- agv/Node.cpp exceeds MSVC's object section limit -- /bigobj on the
main rmf_fleet_adapter target.
- experimental_lift_watchdog's ${rclcpp_LIBRARIES}/${rmf_fleet_msgs_
LIBRARIES}/${std_msgs_LIBRARIES} recursively stack up duplicated
full paths, overflowing link.exe's response-file line limit
(LNK1170) -- same fix as rmf_traffic_ros2/rmf_task_ros2 (switch to
the aggregate/imported targets, WIN32-only).
- robot_state_aggregator_main has a COMPOSITION_BUILDING_DLL define
that nothing in its sources actually branches on, so it has no real
export annotations and MSVC produces the .dll but no import .lib
(LNK1181) -- WINDOWS_EXPORT_ALL_SYMBOLS (single source file, no
LNK1189 risk).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Vendored RxCpp-4.1.0's util::surely() calls an unqualified apply(tpl, detail::surely()), where tpl is a std::tuple -- ADL brings std::apply into the candidate set alongside rxcpp::util::apply (same-namespace, reversed argument order), and MSVC resolves the resulting ambiguity differently than GCC/Clang, ending up instantiating std::tuple_size<rxcpp::util::detail::surely> (the functor, not the tuple) and failing with C2027/C2131/C2672. Fully qualifying the call removes the ADL ambiguity; harmless on every platform since it's the exact same function unqualified lookup would already have found. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ported from humble/jazzy: cancels an in-progress run on the same PR (or ref) when a new push lands, instead of letting multiple full matrix runs pile up and burn CI minutes for commits that are already superseded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rmf_fleet_adapter -- by far the biggest consumer of this library --
surfaced a dozen missing symbols at once: Negotiation (whole class),
MirrorManager/MirrorManagerFuture/make_mirror, blockade::Writer, and
a Graph convert() overload. The selective-export approach (LNK1189
fix) only annotated what rmf_traffic_ros2's own 5 executables needed,
which was never going to be enough for a package this central.
Rather than continuing to chase individual missing symbols one
downstream package at a time, added RMF_TRAFFIC_ROS2_EXPORT across
every class and free function declared in every remaining public
header under include/rmf_traffic_ros2/ (Profile, Route, Trajectory,
agv/Graph, blockade/Writer, geometry/{Circle,ConvexShape,Shape},
schedule/{Change,Inconsistencies,Itinerary,MirrorManager,Negotiation,
ParticipantRegistry,Patch,Query,ScheduleIdentity}, plus the 3
remaining ParticipantDescription.hpp overloads). Verified every
defining .cpp file already includes its own public header (the
missing-include pitfall hit earlier for Node.cpp/MonitorNode.cpp).
This should still stay well under the 65535-symbol import-lib limit
since it only covers the bounded public API surface, not every
internal/template-instantiation symbol the earlier blanket
WINDOWS_EXPORT_ALL_SYMBOLS attempt exported.
Bumps build_number again since build_29 was already published
without these.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The new-file diff section that actually creates include/rmf_traffic_ros2/ detail/export.hpp was accidentally dropped during an earlier patch-file splice/rebuild (likely lost during the ParticipantDescription.hpp section replacement), even though every other header's #include of it survived. Local verification never caught this because it checked file *content* after patching, not that every listed file in the apply sequence actually got created -- the previous "EXIT: 0" checks were real, but I never re-grepped the patch apply's own file list against what should be there. CI caught it immediately: C1083 cannot open include file 'rmf_traffic_ros2/detail/export.hpp'. Restored the section and re-verified end-to-end this time. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The truncation that dropped detail/export.hpp (fixed in 458cc77) also silently dropped two more sections that were positioned after ParticipantDescription.hpp at the time: MonitorNode.cpp's #include <rmf_traffic_ros2/schedule/MonitorNode.hpp> (the fix for make_monitor_node never actually getting dllexported) and the whole Time.hpp export annotations. CI confirmed the MonitorNode.cpp regression directly (LNK2019 unresolved make_monitor_node again). Restored both from the last known-good commit (6a8f481) and verified all 32 files in the patch apply cleanly in one pass this time, not just the file I suspected. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rmf_fleet_adapter.dll had no export annotations at all (58 source files, heavy Eigen/nlohmann/rxcpp use like rmf_traffic_ros2), so every consumer failed with LNK1181. Given rmf_traffic_ros2's blanket WINDOWS_EXPORT_ALL_SYMBOLS attempt hit the 65535-symbol import-lib limit at a similar size, skipped straight to selective export this time: new detail/export.hpp + RMF_FLEET_ADAPTER_EXPORT across the entire public API (only 12 headers here, much more tractable than rmf_traffic_ros2's 23) -- Adapter, EasyTrafficLight, RobotUpdateHandle, FleetUpdateHandle (+ consider_all()), all 8 EasyFullControl-family classes (including its 7 out-of-line-defined nested classes), MockAdapter, Waypoint, Transformation, RobotCommandHandle, ParkRobotIndefinitely, parse_graph. Verified every defining .cpp (or its internal_*.hpp, which several of these route through) actually includes the header carrying the annotation. Also fixed the same LNK1170 legacy-_LIBRARIES pattern (WIN32-only aggregate targets) for 4 more executables that surfaced this round: full_control, mock_traffic_light, door_supervisor, dump_fleet_states. Several other executables in this file still use the same pattern but haven't failed yet -- will fix as they surface. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
read_only_blockade (and read_only, full_control, Adapter.cpp) all directly include src/rmf_fleet_adapter/load_param.hpp -- an internal header not under include/, so it wasn't covered by the public-API export sweep. Its definitions (load_param.cpp) compile into the main library, so the free functions it declares (get_fleet_name_parameter, get_parameter_or_default_time, get_traits_or_default, get_battery_ system, get_mechanical_system) need exporting too for these executables to link. The template get_parameter_or_default() is header-only and needs no export. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…sses Three more internal shared headers (like load_param.hpp) needed exporting since executables include them directly: ScheduleManager.hpp (class + make_schedule_manager/async_make_ schedule_manager), make_trajectory.hpp and estimation.hpp (both global-namespace free functions, no rmf_fleet_adapter:: prefix). Also: RobotUpdateHandle and FleetUpdateHandle each have several inline-defined NESTED classes (ActivityIdentifier, Stubbornness, ActionExecution, Interruption, IssueTicket, Commission, LiftDestination, Unstable; Confirmation, SpeedLimitRequest) whose out-of-line member functions need their own explicit export annotation -- same lesson already learned for rmf_traffic_ros2's MirrorManager::Options. Exported all of them at once (only 2 confirmed failing this round: ActionExecution/Interruption/Unstable, Confirmation/SpeedLimitRequest) rather than waiting for each to surface individually. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…le export hunks The previous commit's "merge" of new nested-class annotations into these two files' existing sections silently dropped the earlier include+outer-class-annotation hunks from df970f5 (confirmed present in that commit's actual diff via git show, so the loss happened in my local intermediate baseline generation, not in what was committed then) -- CI caught it immediately: RMF_FLEET_ADAPTER_EXPORT parsed as an undefined class name (C2079) once the macro's defining include was missing, cascading into dozens of syntax errors throughout both files. Rebuilt both sections from scratch directly against pristine (include + outer class + all nested classes + consider_all() in one pass) and, this time, audited the content of every one of the 29 changed files in this patch against its previously-verified expected export count before pushing, not just confirming `patch` applies without error. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…polate.hpp Same _USE_MATH_DEFINES pattern hit repeatedly this session. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same _USE_MATH_DEFINES pattern hit repeatedly this session (src/FloorplanVisualizer.cpp uses M_PI unconditionally). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same websocketpp boost::is_same pattern as rmf_websocket (MSVC's __cplusplus macro isn't updated without this flag, so websocketpp's feature detection wrongly falls back to a Boost shim recent Boost no longer provides), plus the usual M_PI_2/_USE_MATH_DEFINES gap in test/SubmitTrajectory.cpp. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same uint->unsigned int pattern hit repeatedly this session (src/ScheduleVisualizer.cpp:110's retained_history_count parameter). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Diffed the new WINDOWS_EXPORT_ALL_SYMBOLS change against the wrong baseline (base-patched pristine, predating the /Zc:__cplusplus + _USE_MATH_DEFINES fix), silently dropping that earlier hunk when spliced in -- same class of mistake as rmf_traffic_ros2/rmf_fleet_ adapter earlier. Rebuilt CMakeLists.txt's full win-64 diff in one pass (all three fixes together) directly against the base-patched baseline this time, and verified all three survive in the same independent apply-and-grep check before pushing. rmf_visualization_schedule.dll itself had no export annotations (only 2 source files, so WINDOWS_EXPORT_ALL_SYMBOLS is safe here, no LNK1189 risk), breaking schedule_visualizer's link (LNK1181). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation
Dependency
This branch is rebased onto #38 (Full rebuild August 2026 II + Add RoboPlan packages). Merge #38 first; this PR should be reviewed as the commits after that parent.