Remove tools (dfu-util & openocd) from this repository

[matthijskooijman]

In #158, I wrote:

One way to fix this is to not include precompiled binaries in the core / git repo itself, but use external "tool" zip files which are declared in the platform json file, and are installed by the IDE automatically. This allows using a different zip file for each architecture and thus supporting more different tools.

This is also the method used to install gcc, which refers to the arduino-supplied gcc tool, so that already works for different architectures. It seems that Arduino also supplies a dfu-util tool (also for ARM), which could be used by this core as well (unless maybe that version is too old?).

And @GrumpyOldPizza replied:

On my list of things to do. GCC will be retrieved from somewhere else.

dfu-utils, I am not sure about yet, because we use our own version with some WARs for the ST USB/DFU variant. But, yes same issue. It was just easier to add that to the core archieve initially coming from L4.

Same goes for openocd perhaps as well.

This would solve the 32bit/64bit Linux X86 issues, and the Linux ARM issues.

One big problem though is testing (for me).

Since this seems a broader issue, I thought to create a separate issue for this. I'll post a reply below.

[matthijskooijman]

dfu-utils, I am not sure about yet, because we use our own version with some WARs for the ST USB/DFU variant. But, yes same issue. It was just easier to add that to the core archieve initially coming from L4.

What does "WARs" mean in this context? Local patches to dfu-util?

I've seen that the dfu-util maintainer has been doing some development lately and is responsive to suggestions and patches (no new releases yet, though), so if you have local patches, it might be worth submitting them there, so maybe Arduino can pick them up in their default dfu-util versions, allowing to just use those rather than compiling or at least distributing your own dfu-util versions.

One big problem though is testing (for me).

An advantage of using the Arduino-supplied tools is that they will have had at least basic testing. More specific testing (i.e. does the tool work on all platforms with this particular core) is probably left as an exercise for users of this core (and usually assuming it works on one platform should mean it works on all...).

[GrumpyOldPizza]

Again, on my stack of things to do. At some point of time gcc/dfu-utils/openocd will be unbundled. And, no, not the Arduino supplied variants.

[matthijskooijman]

I wasn't suggesting this should be somehow moved up your stack, it just seemed good to have an issue here to give this some visibility and have a place for dicussion. But if you'd rather not have an open issue for this, then that's also fine.

I'm still curious what "WARs" means, though :-p

In any case, what I forgot to mention before: Thanks for your super-quick replies on my issues and PRs, much appreciated!

[GrumpyOldPizza]

Clicked the wrong button then ... Not sure there is anything to discuss other then "it will come, but not tomorrow".

On Wed, Nov 4, 2020, 08:11 Matthijs Kooijman notifications@github.com wrote:

I wasn't suggesting this should be somehow moved up your stack, it just seemed good to have an issue here to give this some visibility and have a place for dicussion. But if you'd rather not have an open issue for this, then that's also fine.

I'm still curious what "WARs" means, though :-p

In any case, what I forgot to mention before: Thanks for your super-quick replies on my issues and PRs, much appreciated!

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/ArduinoCore-stm32l0/issues/167#issuecomment-721789031, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXBA7DCLIWMMPUX7PPLQZ3SOFVINANCNFSM4TKDPT4Q .