RFC: keep mainstream toolchain versioning format

[leojrfs]

please read #17 (comment)

This PR reverts @samford work and adds aliases to keep the current behaviour

Im not sure why the aliases don't show up in the brew search arm-gcc-bin but they seem to work brew info gcc@8, any hints?

[samford]

There may be value in my original approach in #17 (as described in #17 (comment)) but I didn't want to foist this setup on you unless you felt it was worthwhile. If you want to pursue this, reverting #18 and adding the @10, @9, and @8 aliases makes sense.

At the moment, users can either install the latest version (the arm-gcc-bin alias) or the latest release of a specific major version (e.g., arm-gcc-bin@10). The main benefit of the setup in this PR is that it also allows users to install a specific version without having to worry about it being updated.

The downside is that adding a new version is a little trickier, as you have to add a new formula and update (or add) aliases. With the existing setup, this is only necessary when a new major version is released.

---

Im not sure why the aliases don't show up in the brew search arm-gcc-bin but they seem to work brew info gcc@8, any hints?

Aliases are omitted from brew search results when the formula/cask the alias points to is also in the results (see search.rb). This is the case for brew search arm-gcc-bin on this PR branch, which is why you only see:

osx-cross/arm/arm-gcc-bin@10-2020-q4-major
osx-cross/arm/arm-gcc-bin@8-2019-q3-update
osx-cross/arm/arm-gcc-bin@9-2019-q4-major
osx-cross/arm/arm-gcc-bin@9-2020-q2-update

instead of:

osx-cross/arm/arm-gcc-bin
osx-cross/arm/arm-gcc-bin@10
osx-cross/arm/arm-gcc-bin@10-2020-q4-major
osx-cross/arm/arm-gcc-bin@8
osx-cross/arm/arm-gcc-bin@8-2019-q3-update
osx-cross/arm/arm-gcc-bin@9
osx-cross/arm/arm-gcc-bin@9-2019-q4-major
osx-cross/arm/arm-gcc-bin@9-2020-q2-update

There's maybe something to be said for always displaying aliases in brew search and simply making it clear about what they point to. As it stands, users wouldn't understand that there's an arm-gcc-bin alias if they only used brew search.

I'm busy with some other brew work at the moment but I may make a Homebrew/brew issue for this if I find the time (feel free to beat me to it, if you're interested).

[ladislas]

I'm a bit worried about maintainability. Confusion is easy between update and major.

If we go down this rabbit hole, should we provide formulae for all the arm gcc versions on developer.arm.com?

I would keep arm-gcc-bin for the latest version.

I would only provide @version for only two of the latest versions: @10 & @9, @9 still being widely used.

That being said, I'm afraid it will bring confusion regarding @x pointing to major or update: what happens when @10 gets an update?

Do people really rely on a major when update is available?

Finally, the goal of these formulae was to have arm-gcc up-to-date and easily available, not to provide all the versions needed for every RTOS available out there. It's easy enough for zephyr, contiki and the others to fork the repo if they want and point to the version they need. The burden of maintaining that should not be on us.

ARM Mbed does exactly that https://github.com/ARMmbed/homebrew-formulae

The reason I'm a bit conflicted about this PR is that besides the discussions the 3 of us are having, no one ever asked for that. So is it really worthwhile?

[leojrfs]

If we go down this rabbit hole, should we provide formulae for all the arm gcc versions on developer.arm.com?

That would be my point yes

That being said, I'm afraid it will bring confusion regarding @x pointing to major or update: what happens when @10 gets an update?

We would update the link, since we are the ones deciding which version is considered our @10 release in that case.

Finally, the goal of these formulae was to have arm-gcc up-to-date and easily available, not to provide all the versions needed for every RTOS available out there. It's easy enough for zephyr, contiki and the others to fork the repo if they want and point to the version they need. The burden of maintaining that should not be on us.

I do understand that, but thinking about it, we are tracking the GNU Arm Embedded Toolchain binaries, and not mainstream GCC releases, so we end up defeating the purpose to have real up-to-date GCC for arm releases.

My proposal is not to provide toolchains "for every RTOS available out there", but simply to provide the formulae for the toolchains our mainstream provides.

My example meant to show that using the latest version on a constantly changing toolchain is not so common as it might seem, for instance, a minor release update doesnt mean that it wont break things for some stacks.

Also, I don't really think it is a burden to maintain, its a one time addition every quarter (not even every quarter)

The reason I'm a bit conflicted about this PR is that besides the discussions the 3 of us are having, no one ever asked for that. So is it really worthwhile?

Fair enough, and comes as an argument for what I said previously, but Im not so sure that just because only the 3 of us started this discussion means that nobody wants it. For instance, I wasnt using this repo for all my arm needs because it didnt fit this exact purpose, had to edit the formula before and freeze the version manually.
Point being, those who want to track stable GNU Arm Embedded Toolchains are skipping this formula repo.

So, since this is a bit of a direction change, Id suggest to keep this as an RFC to keep some visibility on this proposal and re-evaluate if we get more thumbs up on this. Sounds fair?

[ladislas]

For instance, I wasnt using this repo for all my arm needs because it didnt fit this exact purpose, had to edit the formula before and freeze the version manually. Point being, those who want to track stable GNU Arm Embedded Toolchains are skipping this formula repo.

Alright, you convinced me, let's move forward! :)

So we should:

• add all the arm-gcc versions as formulae
• make aliases for the "head" of @9 and @10 -- should we also keep @8 and the others? I think 9 and 10 make sense, for the other ones, as they are way older, just the major / update should be fine

Bonus tasks:

• should we implement a simple CI to install the formulae and run a small test, make sure everything is up and running under macOS 10.15 and 11 when it becomes available for everyone?
• I've always had an issue with arm-gcc-bin name: it fits the purpose but now arm means a lot of things, even the latest MacBooks are ARM. Should we use the official gcc-arm-none-eabi name instead? it will also improve seo for people looking to use gcc-arm-none-eabi on macOS

[leojrfs]

Alright, you convinced me, let's move forward! :)

yey!!

add all the arm-gcc versions as formulae

yeah, we could do it ad hoc

make aliases for the "head" of @9 and @10 -- should we also keep @8 and the others? I think 9 and 10 make sense, for the other ones, as they are way older, just the major / update should be fine

To give some context, I think the main point of those should be to keep the same behaviour current users of this repo expect, that being, having the latest versions of major releases. With that said, I think it's a question for the users of that feature in particular. You being one, If not linking @8 makes sense, then so be it 😁

should we implement a simple CI to install the formulae and run a small test, make sure everything is up and running under macOS 10.15 and 11 when it becomes available for everyone?

Im not sure what that implies, but sounds good!

I've always had an issue with arm-gcc-bin name: it fits the purpose but now arm means a lot of things, even the latest MacBooks are ARM. Should we use the official gcc-arm-none-eabi name instead? it will also improve seo for people looking to use gcc-arm-none-eabi on macOS

I agree, altho I'm torn between gcc-arm-none-eabi@ and gcc-arm-embedded@ (as they use to call their Ubuntu ppa packages). The point is this not being a vanilla gcc build. Thoughts?

[ladislas]

With that said, I think it's a question for the users of that feature in particular. You being one, If not linking @8 makes sense, then so be it

From my experience with brew/core, formula is always the latest stable version, if you need something else you'll need to use formula@x which will be the latest stable major version of the x version.

for osx-cross/avr we have something different: avr-gcc is pointing to avr-gcc@9 not avr-gcc@10 -- this is because avr support will be dropped in GCC 11 and that for avr people tend to not like to be cutting edge, so we kept @9 the default.

I think that having the following aliases should be sufficient for now:

• gcc-arm-none-eabi --> latest @9 update
• gcc-arm-none-eabi@9 --> latest @9 update
• gcc-arm-none-eabi@10 --> latest @10-2020-q4-major

This way people installing gcc-arm-none-eabi will have by default the same version as the one provided by ARMmbed. Normal people usually don't jump on the latest version as soon as it comes out. When @10 become the recommend version for ARMmbed, we can point to @10 here.

I agree, altho I'm torn between gcc-arm-none-eabi@ and gcc-arm-embedded@ (as they use to call their Ubuntu ppa packages).

They even call is GNU Arm Embedded Toolchain so we should have that somewhere. Regarding the formula, I'm more in favor of gcc-arm-none-eabi as it's what people will really use and so will want to install. If the name is different, they might wonder if it's really it.

[leojrfs]

They even call is GNU Arm Embedded Toolchain so we should have that somewhere. Regarding the formula, I'm more in favor of gcc-arm-none-eabi as it's what people will really use and so will want to install. If the name is different, they might wonder if it's really it.

Yeah, I think gcc-arm-none-eabi makes more sense! Id say lets go with it!

[ladislas]

@leojrfs where are we with this PR?

[leojrfs]

@leojrfs where are we with this PR?

Sorry, I forgot about this PR.

I'll give it a go if I find time this month.

[ladislas]

@leojrfs I'll convert this PR to draft but reading through our discussion I still think it makes sense to move forward if you have time.

I myself have been in the situation where updating from 13.2Rel1 to 13.3Rel1 broke our firmware but I still think it's interesting to provide the latest version.