Improving experience for those building/packaging on other systems (incl. FreeBSD)

[kevans91]

Currently, getting 1.6.9 IDE up on other systems is a fun little pain. The following hoops exist (so far), with a mild plan for fixing:

• astyle/listSerialPortsC/ctags/arduino-builder/avrdude (at least -- I'm probably missing another one or two) use pre-built versions that are downloaded and used when building the IDE. No option exists for downloading+building these on the current system -- this would likely be addressed with another build system to wrap the ant building stuff and build these dependencies on platforms where it's needed.
• avr-gcc is also downloaded -- is there any particular reason we can't/shouldn't provide an option to use the avr-gcc available in the system PATH? Perhaps surrounded with a scary warning or two to ward people off from using it considering system avr-gcc may not be the version that IDE developers necessarily support.

I'm still playing around with it to see what other problems exist. At this point, I've successfully built the dependencies/IDE (from Ant's perspective, a linux build) and got 1.6.9 up on my FreeBSD laptop. I'm still working through some kinks involving arduino-builder and getting a barebones sketch to compile through the whole process.

Thoughts? Is this worth putting the effort into?

Related:
PR #5138 - stops the IDE from launching successfully upon first build. Presumably due to other issues, but this being a complete show-stopper is rather inconvenient.

[PaulStoffregen]

is there any particular reason we can't/shouldn't provide an option to use the avr-gcc available in the system PATH?

Is creating a tech support nightmare reason enough?

[kevans91]

Is creating a tech support nightmare reason enough?

Perhaps it is reason enough, but it seemed worth mentioning. I personally don't really care for the idea of rebuilding the avr-gcc toolset every time I upgrade the IDE, particularly on an ARM device. I'm also of the 'willing to accept the risk' group that will bite the bullet and downgrade if I really run into issues.

[PaulStoffregen]

The various linux distro packages have historically taken this approach, and historically it's been a terrible mess. The Arduino world is filled with code written by novices, which sometimes has unexpected dependencies on particular toolchain versions.

You really should force yourself to always use the exact same version of the toolchain. Others before you have made the mistake of allowing the incompatible toolchain versions. Please don't repeat history. It's a terrible pain for everyone, especially those of us who answer end user questions. It also tends to give Linux (or BSD) a bad reputation as an unreliable system, especially when forum threads that are easily found by google when people search for the errors they see tend to fill up with the "solution" of the exact same thing working when tried on Mac or Windows.

[kevans91]

Fair point. =)

[kevans91]

@facchinm and others: As far as package_index.json is concerned, how would this effectively be handled?

It occurs to me that there's really not such a thing as a "systems" entry without a "url" specified - is there something we can do at your level to specify that there's compatibility for 'other systems' without providing download information?

[cmaglie]

@kevans91
you need to add a system-tag specifier for freebsd here:

https://github.com/arduino/Arduino/blob/master/arduino-core/src/cc/arduino/contributions/packages/HostDependentDownloadableContribution.java#L44

after that you can provide binaries for freebsd too.
BTW beware that building tools from scratch may be a very tedious task, as Arduino we are already providing three different builds for linux (32, 64 and arm), even if linux-arm users are a very small share of our userbase. We are not going to maintain a build for freebsd anytime soon and you're on your own on that.

[kevans91]

Hi @cmaglie, thanks for that. =)

As for building tools- I've got the following PRs to get building scripted successfully for my platform:

• FreeBSD Support arduino-builder#169 (merged)
• Add compile_freebsd.sh to compile a native build locally listSerialPortsC#7 (merged)
• Amend build scripts for FreeBSD Compatibility; use gmake instead of m… toolchain-avr#37
• Added freebsd.sh compile file. Uses clang to compile, requires java/o… astyle#4
• Add FreeBSD build support, sprinkle some Makefile helpfulness shumatech/BOSSA#22 (against the arduino branch, of course)

All of this being tested bringing up a new build of arduino/Arduino, and working successfully.

As for providing binaries- this is still something that I am thinking on. I don't think the current model of providing binaries for the different supported architectures is necessarily sustainable (especially with potential incompatibilities in different major versions of the OS), but I can't necessarily come up with a better idea.

In fact, the only other idea I've come up with thus far is to simply require the end-user to build everything on, say, FreeBSD. On this platform, it may not necessarily be a big deal- many of us are already used to having to build everything from scratch (well, ports), and the latest versions of the toolchain and other friends that I mentioned above will already be built at install-time. It's mainly going to need to build things at runtime when it's trying to satisfy a different version dependency or when it's a utility (BOSSA, for instance) that's not necessarily included in the stock IDE.

[kevans91]

I think I'll close this. Given that managing this on other systems are a little more challenging to deal with, I suspect my best route at this point is effectively disabling the boards manager and only offering the base AVR boards and possibly the SAM + SAMD boards -- which is effectively what we have now, with 1.0.6.

If I come up with a better idea for managing binary updates to not-officially-supported systems, I'll likely work something up (that doesn't require your intervention) and submit this as a PR rather than trying something like this issue again.

Thank you for your time.