CANBridge: Add support for Linux and macOS #29
Conversation
Note you might need to complie wpilib your self to complie this yourself this is due to wpilib not compling for all versions of linux in the maven repo
There's a lot of warnings that apparently aren't showing up on the Windows build
Fixes broken CANBridge builds on any macOS platform.
Updated workflows to better handle artifact uploads. This includes better cleanup of no longer dumping all the possible platforms into the main directory of the CI job, as well as for each platform type, specific artifacts for each platform is made to lower artifact sizes and to be specific to the correct platform. Added other adjustments for platform types across the workflow for future ARM-specific builds Added macOS artifact creation.
Added builds to utilize Linux ARM 32 and 64 bit versions. Added artifact uploads for Linux versions.
Disabled fail-fast to allow for all other jobs to continue running without interruption, especially if another job fails inside the matrix. Added step to install 7Zip for the Docker CI. This is just to zip and archive up packages without issues.
Steps for unarchiving and archiving HALs are split up to add verbosity to the CI steps, if a specific step fails, we are able to diagnose more quickly. Updated release CI steps, using updated Actions and cleaner methods to check if the build CI completed.
Updated dependent actions due to deprecation notices.
Update artifact uploading workflows, add ARM workflows, update release workflows
This updates workflows to produce headers for CANBridge separately from the built binaries.
Built binaries for macOS are universal for ARM and x86.
The headers artifact was nested by mistake, this is now resolved.
Updated compile instructions and formatting.
The linker flag wasn't needed apparently
|
Other notes to be made, we have added CI to this to validate not only the already existing workflows, but also new builds to support Linux (ARM32/64, and x86) and macOS. Along side those changes, modernizing the existing workflows and modernization to allow directly GitHub Actions to create releases on behalf of the repository. |
|
Thank you for contributing! I expect that this work will be the hardest part of bringing Mac and Linux support to the REV Hardware Client, so if you're successful here, that increases the odds of that happening significantly. I see that you've started with porting the serial driver. Unfortunately, the serial driver only works with SPARK MAX firmware 1.4 and earlier, and the REV Hardware Client doesn't use it at all (it has its own minimal implementation of the serial protocol that is only capable of putting the device in dfu mode). For Linux support, see the SocketCAN branch (see the Linux section it adds to the README). The Linux kernel actually contains a The big lift will be writing a candle/gs_usb driver for Mac. Unfortunately, that protocol is not documented anywhere that I've seen, so if you want to tackle that, you're probably going to have to learn it by reading the Please let me know if you have any questions! Once you have some code that will work with modern REV firmware, I'll give it a more thorough review. |
The @unofficial-rev-port team has been hard at work making the core technologies used by the REV Hardware Client work on all 3 major platforms (Windows, macOS, Linux). This PR contains changes needed for CANBridge to compile and run on macOS and Linux in addition to Windows; and the GitHub Actions changes needed to upload binaries for all 3 OSes for use by the node-can-bridge build process to pull the correct libraries for the 3 platforms (see REVrobotics/node-can-bridge#21).
Please note that this PR is still a work-in-progress; while we have successfully ran a local build of the REV Hardware Client that was able to load and initialize the CAN backend, we are still in the process of testing with real hardware to ensure full functionality (and no regressions) on all 3 OSes. We are opening this PR in the current state in order to gather feedback and make sure we do the changes in a way acceptable to having the PR merged upstream (once completed, of course).