On Tue, Mar 5, 2019 at 4:49 AM Peter Jeremy <[email protected]> wrote: > > On 2019-Mar-04 08:36:52 -0600, Kyle Evans <[email protected]> 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). _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
