[devel/arduino18] Adding a new board description.

[Kyle Evans]

On Tue, Mar 5, 2019 at 4:49 AM Peter Jeremy <peter at rulingia.com> wrote:
>
> On 2019-Mar-04 08:36:52 -0600, Kyle Evans <kevans at freebsd.org> wrote:
> >I'll find some time this week to see what I can do to bring the board
> >manager back. It was removed when I initially ported Arduino 1.6.x
> >because there was some conflict in the functionality itself with how
> >we patch other bits, but I'm foggy on the details at this point
> >because that's been a couple years.
>
> I had a go at re-enabling the board manager and ran into a problem with
> package_index.json.  The port installs native versions of all the IDE
> dependencies, creates links from /usr/local/arduino/tools-builder to the
> native versions and hand-crafts a package_index_bundled.json that says the
> tool runs on the appropriate FreeBSD version (amd64-freebsd12 in my case).
> If I start the board manages, the IDE downloads fresh copy of package data
> and installs it as ~/.arduino15/package_index.json - this version is
> unpatched and therefore only lists the "supported" tool versions (Linux,
> MacOS & Windows), leading to a null pointer exception.
>

Right, I'm starting to remember the details now... they want to
package all of these things up for the platforms they officially
support, but we're not a supported platform so the system absolutely
freaks out and it was a very large rabbit hole (at the time) to go
down for making any of this work. I haven't started the support
conversation yet upstream -- by the time I got all of my other work
upstreamed, I ran out of time to pursue that.

I had asked if I can add some concept of 'unsupported platforms' to
the IDE to bypass a lot of the checks that they do, but I had received
no response and ran out of time to follow-up.

> Interestingly, the release notes for 1.8.2 include:
> * Allow BoardManager to fetch FreeBSD tools (thanks @kevans91)
> so it seems you have previously fixed the board manager, but the fix
> no longer works.
>

This was my start at getting to where we need to be to stop patching
out this functionality, but it turns out there's a lot more hurdles to
talk about.

The path forward for you is unfortunately going to be hacking it out
locally, or we can look at patching it into the arduino-core port. The
level of effort kind of depends on whether it's AVR/SAM/SAMD core or
another core that we don't currently package -- needs range from
patching the core's boards.txt to porting a new core (relatively
easily also).