Open vhdirk opened 9 months ago
Yes, sounds good. When I started this, the naming scheme was changing all of the time, so I just hard-coded everything. But now that they seem to have settled on the X.Y.Rel1 scheme web scraping seems like it should be reliable for a while hopefully. So maybe we could keep the hard-coding for older versions since those shouldn't change and dynamically get newer versions?
That certainly is a possibility; ATM I just scrape both the legacy html page (I also needed versions all the way down to 8) and the 'current' one, looking for any <a href>
tags that match a certain pattern. That way, it doesn't matter all that much what their versioning scheme is.
Furthermore, for macos arm64, the x86_64 variants work fine through rosetta, so I use that as a fallback.
The big drawback here is that for every asdf command, both these webpages have to be scraped again, since it's not possible to construct a download link using only version number, kernel and arch.
I would like to assume that they have indeed settled on arm-gnu-toolchain-<X>.<Y>.<ReleaseNr>-<Kernel>-<Arch>-arm-none-eabi.tar.xz
, but so far, every naming scheme has been used for at most 3 releases, apparently.
Feel free to make a pull request. IIRC, sometimes they change the zip type too without changing the rest of the naming scheme.
For some reason, I didn't immediately find this plugin when I needed it, so I wrote my own: https://github.com/vhdirk/asdf-gcc-arm-none-eabi
My implementation scans the arm website for versions rather than having to update the asdf plugin every time a new gcc version is released. Your plugin on the other hand, seems to have support for windows hosts.
I wonder if we could join forces by merging our plugins?