Repository navigation
Add rmf_dev - #114
Open
Tobias-Fischer wants to merge 47 commits into
Open
Add rmf_dev#114Tobias-Fischer wants to merge 47 commits into
Tobias-Fischer wants to merge 47 commits into
Conversation
Ports RoboStack/ros-humble#298. humble's rmf_traffic 3.0.3 gets the Apple Clang fix from open-rmf/rmf_traffic#98, <cassert> in its bundled fcl and Eigen3::Eigen (Eigen 5 no longer sets EIGEN3_INCLUDE_DIRS); rmf_utils includes <string>; nlohmann_json_schema_validator_vendor passes CMAKE_POLICY_VERSION_MINIMUM to its external project (CMake 4). Co-authored-by: Wen-Chung (Andy) Cheng <[email protected]> Co-Authored-By: Claude Opus 5.5 <[email protected]>
Found building rmf_dev's closure for humble on osx-arm64 (humble never built RMF before): - rmf_traffic: also the test part of open-rmf/rmf_traffic#98 - rmf_websocket: Boost.System is header-only (no boost_system since 1.89) - rmf_traffic_ros2: lyrical's patch (macOS uuid comes from the SDK, Eigen3::Eigen) - rmf_fleet_adapter: malloc.h/malloc_trim only on Linux, RxCpp's const copy-assignment removed (newer clang rejects it), std::max<int64_t> and std::size_t lane vectors (uint64_t is unsigned long long on macOS) - rmf_robot_sim_common: EIGEN3_INCLUDE_DIRS from Eigen3::Eigen (Eigen 5), sdformat parameters read as uint64_t - rmf_robot_sim_gz_plugins: link the gazebo gui library, drop a declared but never defined slot - rmf_building_sim_gz_classic_plugins: OpenCV 5 geometry header, link libgazebo; excluded off Linux (Gazebo Classic, more link errors on macOS) - rmf_building_map_tools: its patch is upstream in 1.6.3 (np.asscalar) - robostack.yaml: map ignition-fortress to the Fortress libraries Co-Authored-By: Claude Opus 5.5 <[email protected]>
…and jazzy [skip ci] jazzy's 0.4.1 (needed by rmf_dev there) fails the same way as humble's 0.2.5: its external project declares cmake_minimum_required < 3.5. The same one-line patch applies to both, so share it; lyrical and rolling keep their own patch for 0.6.1/0.5.0. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…ion [skip ci] The shared pkg_additional_info.yaml builds pybind11_json_vendor with AMENT_VENDOR_POLICY=NEVER_VENDOR, but only humble and lyrical added pybind11_json as a dependency, so jazzy (pulled in by rmf_dev) failed: "SATISFIED argument is not TRUE, but AMENT_VENDOR_POLICY is set to NEVER_VENDOR". Move the dependency to the shared dependencies.yaml. Co-Authored-By: Claude Opus 5.5 <[email protected]>
rmf_dev also brings rmf_traffic 3.3.3 to jazzy, which fails with GCC 15: ParticipantDescription.hpp uses uint16_t/uint64_t without <cstdint>. Add that include, plus lyrical's rmf_traffic changes (Eigen3::Eigen for Eigen 5, <cassert>), which apply unchanged. Co-Authored-By: Claude Opus 5.5 <[email protected]>
rmf_task (<cstdint>, needed by GCC 15 on linux-64), rmf_building_map_tools (numpy 2 cross product), rmf_visualization_floorplans (OpenCV imread flag), rmf_visualization_schedule (standalone asio, Boost 1.90), and for jazzy rmf_utils (WINDOWS_EXPORT_ALL_SYMBOLS) and rmf_traffic_ros2 (macOS LibUUID). humble's rmf_utils patch gains the Windows export hunk. All apply cleanly to the sync snapshot tags. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…en 5 [skip ci] Eigen 5's CMake config only provides the Eigen3::Eigen target, not the Eigen3_INCLUDE_DIRS that ament_target_dependencies and these CMakeLists use: floorplans now links Eigen3::Eigen, and robot_sim_common takes humble's patch (which also reads the sdformat size_t parameters as uint64_t on macOS). Co-Authored-By: Claude Opus 5.5 <[email protected]>
…ls patch [skip ci] Boost 1.90 has no boost_system library (Boost.System is header-only), so rmf_websocket's find_package(Boost COMPONENTS system) fails: link Boost::headers instead. The rmf_utils Windows export taken from rolling duplicates the jazzy sync's own ros2-rmf-utils.win.patch, so remove it again. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…hedule patch [skip ci] Boost 1.90 removed asio::io_service with its post()/dispatch() members. conda-forge's websocketpp 0.8.2 is already patched to io_context (get_io_context()), so jazzy's rmf_websocket only needs its own uses switched: io_context, boost::asio::post/dispatch. No standalone Asio. rolling's rmf_visualization_schedule patch (ASIO_STANDALONE) isn't needed here: neither distribution's source uses Asio directly, humble's built with Boost 1.90 without it, and it would need asio as an extra dependency. Co-Authored-By: Claude Opus 5.5 <[email protected]>
The OpenCV hunk taken from rolling isn't needed for humble or jazzy: their uint8[] message fields are std::vector<uint8_t>, which cv::Mat accepts, and humble built without it. jazzy keeps the Eigen3::Eigen link. Co-Authored-By: Claude Opus 5.5 <[email protected]>
The bundled RxCpp 4.1.0 assigns to a const exception_ptr in on_error_notification's operator=, which GCC 15 now rejects; humble's patch removes it. The macOS fixes carry over from humble's patch as well (malloc_trim is Linux-only; int64_t and uint64_t aren't long and size_t there), plus a cast for the route_id comparison in ExecutePlan that jazzy's source has and humble's doesn't. Co-Authored-By: Claude Opus 5.5 <[email protected]>
From humble's patch, for the same code: Database and Mirror declare their participant overrides with std::size_t where the base class uses ParticipantId (uint64_t), which isn't std::size_t on macOS, so clang rejects them as hiding the virtual functions; and the bundled fcl and blockade/geometry.cpp use assert without <cassert>, which libc++ doesn't include for them. The test-only hunk isn't needed: the tests aren't built. Co-Authored-By: Claude Opus 5.5 <[email protected]>
The tests are built after all (the earlier failure stopped before them): test_Spacetime.cpp names libstdc++'s internal std::chrono::_V2 namespace, which libc++ doesn't have. As in humble's patch, use std::chrono. Co-Authored-By: Claude Opus 5.5 <[email protected]>
The LightTuning GUI plugin derives from gz::sim::GuiSystem, which lives in gz-sim's gui library, but only links gz-sim::core; Linux allows the symbols to stay undefined, macOS doesn't. Request the gui component and link gz-sim::gui. It also declares OnLightTypeSelect() without ever defining or using it, which leaves an undefined vtable-free reference from the moc code on macOS: drop the declaration. Same fixes as humble's patch, for the gz (not Ignition) names. Co-Authored-By: Claude Opus 5.5 <[email protected]>
ament_target_dependencies(... OpenSSL ...) looks for OpenSSL_LIBRARIES, which FindOpenSSL doesn't set (it sets OPENSSL_LIBRARIES), so the library never linked libssl/libcrypto. Linux lets the symbols stay undefined, macOS doesn't (_BIO_free_all, ...). Link OpenSSL::SSL and OpenSSL::Crypto, as humble's version of the package does. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…skip ci]
pybind11_add_module(rmf_adapter SHARED ...) makes pybind11 link
pybind11::embed, i.e. libpython. On macOS, where python itself has the
interpreter built in, `import rmf_adapter` then aborts ("PyInterpreterState_Get:
the function must be called with the GIL held"): the module initialises
the second, never-started interpreter in libpython. This affects the
published osx-arm64 builds of every distribution (checked rolling 2.12.0
and humble 2.1.8). Nothing links against rmf_adapter, so build it as the
default MODULE, which links pybind11::module (no libpython).
Shared: applies to humble 2.1.8, jazzy 2.7.2, lyrical 2.13.0 and rolling
2.12.0. Tested on jazzy osx-arm64: the module no longer links libpython,
and `import rmf_adapter` plus a Graph() call work. Upstream
(open-rmf/rmf_ros2 main) still uses SHARED.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
…rks [skip ci] Regression test for the SHARED -> MODULE fix: import rmf_adapter (and easy_full_control) and build an empty Graph. With the SHARED build the import aborts on macOS. Passes on jazzy osx-arm64. Co-Authored-By: Claude Opus 5.5 <[email protected]>
humble's rmf_adapter 2.1.8 has no easy_full_control, and isn't a package there (import rmf_adapter.graph fails), so use the submodules as attributes. Passes on humble 2.1.8 and jazzy 2.7.2 (osx-arm64). Co-Authored-By: Claude Opus 5.5 <[email protected]>
…p ci] - rmf_traffic_ros2: the same patch in all four distributions -> shared. - rmf_building_map_tools: the same numpy 2 fix in all four (lyrical's worded differently) -> shared; lyrical's package changes accordingly. - rmf_robot_sim_common: humble's and jazzy's were the same -> shared (it applies to lyrical's and rolling's too, which don't build it: no rmf_dev release there). - rmf_traffic: jazzy's patch is humble's plus the <cstdint>/<cassert> includes jazzy needs, and applies to humble -> shared for both; lyrical and rolling keep their own. Built humble's rmf_traffic with it on osx-arm64, with its tests. Every distribution's effective patch was checked against its sync source. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…the Fortress ones there conda-forge has gazebo 11 for win-64 (and humble already builds gazebo_ros there), so only macOS keeps excluding rmf_*_sim_gz_classic_plugins. rmf_building_sim_gz_plugins and rmf_robot_sim_gz_plugins need Ignition Fortress (libignition-gazebo6), which isn't installable on win-64, as for gz_ros2_control. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Tobias-Fischer
added
build:humble
…ffect for lyrical and rolling vinca takes a package's patches from one layer only: a distribution's patch for a package (any platform) replaces all of shared/'s for it. So lyrical's and rolling's rmf_traffic_ros2 and rmf_fleet_adapter_python Windows patches hid the shared rmf_traffic_ros2 patch and the shared MODULE fix on every platform: - rmf_fleet_adapter_python: the (identical) lyrical/rolling Windows patch moves to shared/, so every distribution gets the MODULE fix and the Windows fix; - rmf_traffic_ros2: lyrical and rolling get their own copy of the generic patch back. Windows for humble and jazzy (CI failed in menge_vendor): - menge_vendor: build with MENGECORE_EXPORTS (dllexport), no libdl; - lyrical's Windows patches ported to humble's and jazzy's RMF sources (api_msgs, battery, fleet_adapter, task, task_ros2, task_sequence, visualization_floorplans, visualization_schedule, websocket per distribution; rmf_traffic and rmf_traffic_ros2 in shared/, as their generic patches), with the hunks for code they don't have dropped (rmf_reservation_msgs, LiftDestination, ...); - rmf_building_sim_common, rmf_robot_sim_common: CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…ot_sim_common _USE_MATH_DEFINES (M_PI); rmf_traffic_editor links the PROJ and yaml-cpp imported targets and doesn't include the (unused) unistd.h / pwd.h. Co-Authored-By: Claude Opus 5.5 <[email protected]>
ABI check (linux-64)humble linux-64: **10 need their dependents rebuilt**, 2 to review (changed headers), 3 can be bumped on their own
3 packages can be bumped on their own (compatible: 1, no libraries: 2)
Compared with the newest builds on https://conda.anaconda.org/robostack-humble/linux-64. jazzy linux-64: 1 can be bumped on their own1 packages can be bumped on their own (compatible: 1)
Compared with the newest builds on https://conda.anaconda.org/robostack-jazzy/linux-64. lyrical linux-64: **1 need their dependents rebuilt**, 5 can be bumped on their own
5 packages can be bumped on their own (compatible: 5)
Compared with the newest builds on https://repo.prefix.dev/robostack-lyrical/linux-64. rolling linux-64: **1 need their dependents rebuilt**, 5 can be bumped on their own
5 packages can be bumped on their own (compatible: 5)
Compared with the newest builds on https://repo.prefix.dev/robostack-rolling/linux-64. About this checkEach package this pull request built, compared with its newest released build (
Exported symbols are compared (the released packages are stripped, so struct layouts aren't); unchanged installed headers rule out layout and inline changes, changed ones are listed for review. Dependents to rebuild are the released ones linking to a changed library. A changed pin is part of the comparison. |
From lyrical's patch: a short ExternalProject name and prefix (the hash-named layout exceeded MAX_PATH: "'$GIT_DIR' too big"), BUILD_COMMAND as tokens, and CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS for the validator library. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…dator's tests The older validator in humble/jazzy names its options BUILD_TESTS/BUILD_EXAMPLES; its test links draft7_schema_builtin, a data symbol export-all doesn't export. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…mble) NOMINMAX (Menge's and Gazebo's windows.h min/max macros broke rclcpp's headers, C2589) and _USE_MATH_DEFINES. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…e, jazzy) Its CMakeLists.txt adds -Wall -Wshadow -Wextra unconditionally; MSVC stops on -Wshadow (D8021: invalid numeric argument '/Wshadow'). lyrical's 1.14.1 builds. Co-Authored-By: Claude Opus 5.5 <[email protected]>
windows.h, pulled in by its dependencies, declares GDI's Polygon(), which clashes with the editor's Polygon class (level.h: C2923 'Polygon' is not a valid template type argument). Co-Authored-By: Claude Opus 5.5 <[email protected]>
Tobias-Fischer
added
the
build:rolling
SchedulePanel.cpp uses the alternative operator tokens (`or`); MSVC knows them only with <iso646.h> (C2065: 'or': undeclared identifier). Co-Authored-By: Claude Opus 5.5 <[email protected]>
…e); no rmf_visualization_schedule tests - humble's rmf_fleet_adapter linked the bare name yaml-cpp (LNK1181: cannot open input file 'yaml-cpp.lib'); jazzy and later already link the target. - rmf_visualization_schedule's test_submit_trajectory link command exceeds the linker's line limit (LNK1170); its tests are off on Windows. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…dule tests behind BUILD_TESTING (jazzy) - humble's rmf_fleet_adapter: MSVC 14.44 crashes compiling full_control's main.cpp (C1001 in type_traits); try it unoptimized (/Od). - jazzy's rmf_visualization_schedule adds its test directory unconditionally, so BUILD_TESTING=OFF didn't help against LNK1170: guard it. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…ask_aggregator's link line - MSVC 14.44 crashes compiling full_control/main.cpp (C1001 in its lambda handling; /Od didn't help), so that executable isn't built or installed on Windows; lyrical's and rolling's newer releases build it. - jazzy's task_aggregator overflowed link.exe's response-file line limit (LNK1170) like full_control: link the imported targets on Windows. Co-Authored-By: Claude Opus 5.5 <[email protected]>
… class rmf_fleet_adapter_python links RobotUpdateHandle::Unstable::Stubbornness::release (LNK2001); nested classes don't inherit dllexport. jazzy's patch already has it. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…the DLLs to bin Both installed RUNTIME (on Windows also the DLL) into lib/<pkg>, which isn't on PATH, so rmf_fleet_adapter_python's rmf_adapter.pyd failed to load. The fleet adapter's executables stay in lib/rmf_fleet_adapter. Co-Authored-By: Claude Opus 5.5 <[email protected]>
…in too Like rmf_fleet_adapter: their DLLs went to lib/<pkg> with the executables, so rmf_adapter.pyd still couldn't load. rmf_traffic_ros2's patch is shared by two releases with different install blocks, so it installs a second copy of the DLL to bin. Co-Authored-By: Claude Opus 5.5 <[email protected]>
rmf_traffic_ros2 links rmf_utils.dll, which was installed to lib (not on PATH), so rmf_adapter.pyd still failed to load. rmf_utils is already published, hence the build_number bump. ci.yaml: evictions reset (the packages have been rebuilt). Co-Authored-By: Claude Opus 5.5 <[email protected]>
Tobias-Fischer
removed
the
build:win
… packages The published lyrical and rolling win-64 packages have rmf_utils, rmf_websocket, rmf_traffic_ros2, rmf_task_ros2 and rmf_fleet_adapter DLLs in lib/ or lib/<pkg>, so rmf_adapter.pyd can't load them. Same fix as for humble and jazzy. All are published, so their build numbers are bumped, also rmf_fleet_adapter_python's: CI skipped it, so the shared MODULE fix hadn't reached lyrical and rolling. rolling's rmf_utils.win.patch repeated its generic patch's WINDOWS_EXPORT_ALL_SYMBOLS; rolling's rmf_websocket.win.patch is refreshed on top of its generic patch. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Tobias-Fischer
added
build:win
lyrical's rmf_adapter fails with 'A dynamic link library (DLL) initialization routine failed'; load its dependencies one by one to see which. To be removed again. Co-Authored-By: Claude Opus 5.5 <[email protected]>
… (temporary) rmf_task_sequence.dll is the one that fails to initialise: it constructs json_validator objects during static initialisation. Build the same one in a small program to see the exception. To be removed again. Co-Authored-By: Claude Opus 5.5 <[email protected]>
It showed conda-forge's json_schema_validator 2.4.1 (lyrical) is a Debug build on win-64 (MSVCP140D.dll): rmf_task_sequence's static json_validator crashes in it (conda-forge/json_schema_validator-feedstock#19). Co-Authored-By: Claude Opus 5.5 <[email protected]>
Tobias-Fischer
added
build:none
pkg_additional_info.yaml: both sides' build_number entries (#116, #118). Co-Authored-By: Claude Opus 5.5 <[email protected]>
Collaborator
Author
Tobias-Fischer
removed
the
build:none
Tobias-Fischer
marked this pull request as ready for review
November 4, 2026 01:52
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
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.
Ports RoboStack/ros-humble#298 by @Ac31415: adds
rmf_devto the shared selection (next tormf_demos, which jazzy, lyrical and rolling already build). Building it on top of the syncs turned up fixes for humble (which hasn't built RMF yet), for jazzy (rmf_devpulls in more of RMF thanrmf_demos, and jazzy hadn't been built on GCC 15 / macOS with it), and one for every distribution.All distributions (shared patch)
rmf_fleet_adapter_python:rmf_adapteris built as a PythonMODULEinstead ofSHARED. WithSHARED, pybind11 linkspybind11::embed(libpython), and on macOSimport rmf_adapteraborts (PyInterpreterState_Get: … the GIL is released): the module initialises a second, never-started interpreter. The published osx-arm64 builds have this today (checked rolling 2.12.0, and humble's local build). Upstream main still usesSHARED. A new recipe test (shared/tests/ros2-rmf-fleet-adapter-python.yaml) importsrmf_adapterand builds aGraph; it passes on humble and jazzy (osx-arm64). Applies to humble 2.1.8, jazzy 2.7.2, lyrical 2.13.0 and rolling 2.12.0; lyrical and rolling get abuild_numberbump for it (31, 33), as the package is published there.nlohmann_json_schema_validator_vendor0.2.5 (humble, jazzy):CMAKE_POLICY_VERSION_MINIMUM=3.5for its external project (CMake 4), moved from humble's patch toshared/.pybind11_json_vendor: host and run dependency on conda-forge'spybind11_json, for every distribution (moved from humble's and lyrical'sdependencies.yaml).humble
rmf_traffic3.0.3: Fix build with Apple Clang open-rmf/rmf_traffic#98 (Apple Clangfinal/ParticipantIderrors, as diagnosed by @traversaro in that PR),<cassert>in its bundled fcl,Eigen3::Eigen(Eigen 5 no longer setsEIGEN3_INCLUDE_DIRS).rmf_task2.1.8:<cstdint>(its headers useuint32_twithout it; GCC 15 doesn't include it for them). From rolling's patch.rmf_utils1.4.1:#include <string>inModular.hpp;WINDOWS_EXPORT_ALL_SYMBOLSon Windows (from rolling's patch).rmf_websocket: Boost.System is header-only (noboost_systemlibrary since Boost 1.89).rmf_traffic_ros2: lyrical's patch (macOSuuidfrom the SDK,Eigen3::Eigen).rmf_fleet_adapter:malloc.h/malloc_trimonly on Linux; RxCpp's copy assignment of aconstmember removed (newer clang and GCC 15 reject it);std::max<int64_t>andstd::size_tlane vectors (uint64_tisunsigned long longon macOS).rmf_robot_sim_common:EIGEN3_INCLUDE_DIRSfromEigen3::Eigen; sdformat parameters read asuint64_t.rmf_robot_sim_gz_plugins: links the Gazebo gui library (GuiSystem); a declared but never defined slot removed.rmf_building_sim_gz_classic_plugins: OpenCV 5'sgeometry.hpp,${GAZEBO_LIBRARIES}; it andrmf_robot_sim_gz_classic_plugins(Gazebo Classic, EOL) are excluded off Linux, after more link errors on macOS.rmf_building_map_tools1.6.3: the old humble patch is obsolete (upstream removednp.asscalar); rolling's numpy 2 fix for the 2-Dnp.crossinstead.robostack.yaml: maps theignition-fortressrosdep key to the Fortress libraries.jazzy
rmf_traffic3.3.3:<cstdint>inParticipantDescription.hpp(GCC 15), and from humble's patch for the same code the macOS fixes (ParticipantIdoverrides,<cassert>in fcl andblockade/geometry.cpp,std::chronoinstead of libstdc++'sstd::chrono::_V2in a test).rmf_task2.5.1:<cstdint>(GCC 15), from rolling's patch.rmf_fleet_adapter2.7.2: humble's RxCpp fix (GCC 15) and macOS fixes, plus asize_tcast for aroute_idcomparison inExecutePlan.cpp.rmf_websocket2.7.2: no Boost.System, andasio::io_service(removed in Boost 1.90) →io_contextwithboost::asio::post/dispatch. conda-forge's websocketpp is already onio_context, so no standalone Asio.rmf_visualization_schedule2.3.2: linksOpenSSL::SSL/OpenSSL::Crypto;ament_target_dependencies(OpenSSL)linked nothing (it looks forOpenSSL_LIBRARIES), which only macOS rejects.rmf_visualization_floorplans2.3.2 andrmf_robot_sim_common2.3.3:Eigen3::Eigen(Eigen 5);rmf_robot_sim_commontakes humble's patch.rmf_robot_sim_gz_plugins2.3.3: as humble, for the gz names (gz-sim::gui).rmf_traffic_ros22.7.2 andrmf_building_map_tools1.9.2: rolling's patches (macOSLibUUID; numpy 2np.cross).Not taken over from rolling: its
rmf_visualization_schedule(standalone Asio, needs an extra dependency; neither distribution's source uses Asio directly and humble built without it),rmf_visualization_floorplansOpenCV change (not needed: humble and jazzy'suint8[]fields arestd::vector<uint8_t>), andrmf_utilsfor jazzy (the jazzy sync already has it asros2-rmf-utils.win.patch).Windows (humble, jazzy):
rmf_devbuilds on win-64 too. lyrical's and rolling's Windows patches were the starting point; humble had none.rmf_fleet_adapterandrmf_traffic_ros2(shared patch) get dllexport annotations (detail/export.hpp, also on nested classes such asRobotUpdateHandle::Unstable::Stubbornness);rmf_fleet_adaptercan't use export-all (more than 65535 objects for the import library).rmf_traffic,rmf_task,rmf_task_sequence,rmf_task_ros2,rmf_battery,rmf_websocket,rmf_visualization_schedule,rmf_utils,rmf_building_sim_common,rmf_robot_sim_commonand the JSON schema validator export all symbols.rmf_utils,rmf_websocket,rmf_traffic_ros2,rmf_task_ros2andrmf_fleet_adapterinstalled their DLLs tolib/<pkg>(with the executables) orlib, which aren't onPATH, soimport rmf_adapterfailed; they now go tobin(rmf_traffic_ros2, shared by two releases, installs a second copy there).rmf_utilsis already published, so itsbuild_numberis bumped in humble and jazzy.build_numberbumps (lyrical 31, rolling 33) forrmf_utils,rmf_websocket,rmf_traffic_ros2,rmf_task_ros2,rmf_fleet_adapterandrmf_fleet_adapter_python. rolling'srmf_utils.win.patchrepeated its generic patch;rmf_websocket.win.patchis refreshed on top of the generic one._USE_MATH_DEFINESforM_PIin several packages (rmf_task,rmf_battery,rmf_traffic_examples, …) andNOMINMAXinrmf_building_sim_common(Menge includeswindows.h);rmf_traffic_editorwithout GCC warning flags and withNOGDI;rmf_visualization_rviz2_pluginsforce-includes<iso646.h>(or);rmf_fleet_adapterlinksyaml-cpp::yaml-cppand imported targets (task_aggregator, LNK1170);rmf_api_msgsruns its generator without the shellevaland withpython.exe;menge_vendordoesn't linkdl;nlohmann_json_schema_validator_vendor's external project gets a build command MSBuild understands and a shorter path (MAX_PATH);rmf_traffic_editor_test_mapsgenerates its worlds without downloading models.rmf_fleet_adapter'sfull_controlexample executable (MSVC 14.44 crashes compiling it, C1001, also unoptimized);rmf_visualization_schedule's tests (LNK1170). humble excludes the Gazebo Classic plugins (rmf_*_sim_gz_classic_plugins, noOgreBites.libon win-64) and, on win-64, the Ignition Fortress ones (rmf_*_sim_gz_plugins, Fortress isn't installable there); jazzy's gz plugins build.Patch layout: where the distributions had the same patch, it's in
shared/patch/(rmf_traffic_ros2,rmf_building_map_tools,rmf_robot_sim_common, andrmf_trafficfor humble and jazzy, with lyrical and rolling keeping theirs); the rest stay per distribution because their sources differ (rmf_fleet_adapter,rmf_websocket,rmf_robot_sim_gz_plugins,rmf_task, …).Built locally (on top of the syncs, see below)
rmf_devand its whole closure (321 packages) with recipe tests. In a fresh environment from these packages,import rmf_adapter(witheasy_full_control,graph) works andGraph()runs, after theMODULEfix; the new recipe test passes there.rmf_devand its closure (about 350 packages) with recipe tests;rmf_fleet_adapter_pythonrebuilt with theMODULEfix: it no longer links libpython, and the new recipe test passes (the build before the fix had the same crash).rmf_devrelease for them (rmf_demos only), so the selection only adds it for humble and jazzy. What changes for them are the shared patches:rmf_fleet_adapter_python(MODULE fix) and lyrical'srmf_building_map_tools(now the shared wording of the same numpy 2 fix);rmf_traffic_ros2is unchanged in content. Not rebuilt locally.CI: Windows green for humble and jazzy (lyrical and rolling have no
rmf_devrelease; they rebuild the bumped packages); full build on all platforms running. The syncs it was prepared on are merged.🤖 Generated with Claude Code