Closed thinkyhead closed 2 years ago
Thanks for sorting this out, it shouldn't be necessary to fork as long as the HAL API doesn't change constantly, I prefer to keep this as an external library. Where I drew the line at what is in the Marlin HAL implementation and what I moved to the library could be tweaked if its a problem.
I will sort out a release, possibly push it to PlatformIOs library manager too although direct links are fine as its just a dev tool don't need to worry as much about backwards compatibility.
Current versions of Marlin refer to master.zip
specifically, which is why I thought it may be better to keep that branch as it is, then put these changes in a new branch that can start to have version tags. Since GitHub is leaning towards "main" to replace "master" maybe you can put the new versioned code into a branch with that name…? If in future you want to delete the "master" branch, then a tag called "master" should automagically work in its place.
Being a development tool MarlinSimUI has only tried to be compatible with Marlin bugfix-2.0.x so Marlins native.ini targets the master branch as it should, the master branch is currently not compatible with any previous version of Marlin.
If you need to have a compatible version for each official Marlin release then that could be done, although you would need to update native.ini before each release to target the "stable" version, .. or just target a specific commit.
You probably already reverted this, as there were bugs when I tried to apply the change to all the HALs at once. I'll try and apply it more gradually for better chance of success.
Please revert.
Updated API for HALs proposed for Marlin 2.0.9.3. A new version tag – or branch – will be required for the benefit of
ini/native.ini
. Or, we could host a fork ofMarlinSimUI
underMarlinFirmware
… if that's easier to manage.See MarlinFirmware/Marlin#23295