TL;DR: kill https://github.com/wpilibsuite/bzlmodRio-libssh, update
versions, and make things easier for a script to update.
The main motivation behind this was that libssh was out of date with the
gradle version. Using these "external" dependencies can cause agita as
we churn through toolchain updates. Unlike the toolchains and opencv,
which can be used by external users (i.e. a all bazel robot, if a vendor
wanted to use bazel) a C++ wrapper around libssh maven deps almost
certainly wouldn't be pulled in, much like ceres and mrclib.
As a result of vendor'ing libssh, and knowing some potential pitfalls
and annoyances, this PR does the following:
- Vendor libssh, akin to how mrclib is pulled in
- Moves the vendor'd ceres to `shared/bazel/thirdparty`, and refactors
it to better match mrclib. To me it doesn't necessarily belong in its
`thirdparty` location because it is bazel only.
- Due to the refactoring, libssh and ceres can now be pulled into
`MODULE.bazel` instead of the `WORKSPACE.bzlmod` helper. This is good
prep for a potential upgrade to killing `--enable_workspace` / bazel 9
- Write a python script that can deal with the integrity / sha256 of the
http_archives. I suggested this be added to davo's mrclib PR, but this
one is a little bit more robust and will actually edit the files in
place. This makes upgrading versions substantially easier.
- Upgrade libssh version to what gradle is using, and mrclib to the
version in #8858. These changes have been tested against that PR.
Right now, the `zipBaseName` variable in various publish.gradle files
contains the group ID and artifact ID for use by the combiner, however,
they are also duplicated in `artifactGroupId` and `baseArtifactId`,
leading to potential mistakes if they aren't updated together. This
fixes that by adding a new utility function `makeZipBaseName` to
automatically create the right name given a group ID and artifact ID.
This also fixes publishing for thirdparty subprojects, which didn't
update `zipBaseName`.
This lets us remove the unmaintained StackWalker library and its hacky
upstream_utils script.
@Gold856 reported that StackWalker gives blank stacktraces:
https://discord.com/channels/176186766946992128/368993897495527424/1261940029287301150.
They also reported an earlier version of this PR giving the following
stacktrace instead:
```
D:\allwpilib\developerRobot\src\main\native\cpp\Robot.cpp(18): developerRobotCpp!Robot::RobotInit+0xB6
D:\allwpilib\wpilibc\src\main\native\cpp\TimedRobot.cpp(22): wpilibcd!frc::TimedRobot::StartCompetition+0x4F
D:\allwpilib\wpilibc\src\main\native\include\frc\RobotBase.h(36): developerRobotCpp!frc::impl::RunRobot<Robot>+0xC8
D:\allwpilib\wpilibc\src\main\native\include\frc\RobotBase.h(106): developerRobotCpp!frc::StartRobot<Robot>+0x17E
D:\allwpilib\developerRobot\src\main\native\cpp\Robot.cpp(60): developerRobotCpp!main+0xB
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): developerRobotCpp!invoke_main+0x39
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): developerRobotCpp!__scrt_common_main_seh+0x132
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): developerRobotCpp!__scrt_common_main+0xE
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): developerRobotCpp!mainCRTStartup+0xE
KERNEL32!BaseThreadInitThunk+0x1D
ntdll!RtlUserThreadStart+0x28
```
This primarily fixes up the bazel publishing to match the gradle
publishing again, as some new libraries were added but not hooked up to
the maven publishing.
During the process, I noticed that the 3rd party libraries (googletest,
catch2, and imgui_suite) were still getting published on the old
`edu.wpi` namespace. I tried to clean up all the other references to
that that I could. Note: opencv and libssh are handled outside
`allwpilib` so they need to be updated separately.
This uses all the infrastructure we put together earlier to actually build and publish all the artifacts.
We might still want to adjust what is built by default to control CI times.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
Co-authored-by: PJ Reiniger <pj.reiniger@gmail.com>
Co-authored-by: David Vo <auscompgeek@users.noreply.github.com>
This pulls down the prebuilt ceres libraries and uses them with Bazel to
build and test wpical.
Do note that bazel looks up artifacts used for testing differently than
the other build systems. It wants you to use its runfiles API to find
the dependencies reliably. Add a function to look up the paths for
files, and use runfiles only when building with Bazel to maintain
compatibility with other languages.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
* `-Wfixed-enum-extension` was replaced with `-Wc23-extensions`
* Removed unused private variables in SysId
* Suppressed `-Wnontrivial-memcall` in imgui.h and imgui_internal.h