[ci] Magic packets for TravisCI

[strongly-typed]

The .travis.dep.sh downloads two magic packets from the Internet (http://box.xpcc.io/avr-gcc.tar.bz2 and http://box.xpcc.io/boost.tar.bz2).

When, how, and who created these magic tar balls. I only know 1/3 of the answer. There should be a reproducible, documented way how to create these. It's fine for me to rely on ARM providing the toolchain tar balls for Cortex-M.

I was able to build the latest 3.6.1 AVR toolchain in a Docker container.

[salkinium]

I built them on the Ubuntu server that hosts them, so that TravisCI doesn’t have to build them over and over again. I already forgot how I did that. I’m ready to remove Travis CI and only use Circle CI.

[salkinium]

Would also break when I remove that server or misconfigure the subdomain or something, so we should definitely not rely on it.

[strongly-typed]

In TravisCI, we use the compiler you provide. Is seems to be a compiler from Atmel.
gcc version 5.4.0 (AVR_8_bit_GNU_Toolchain_3.4.4_201706301059). The 3.4.4 is definitely wrong. This is caused by a bug in Atmel's build script. Hey Atmel, do you have QA?

Why exactly don't we use the avr-gcc we could install in TravisCI's Ubuntu? Because Travis is based on Ubuntu 14.04 and the compiler in 14.04 is too old? Travis seems to stick to good old 14.04.

In CircleCI, we use the AVR GCC from Ubuntu 16.04, which is not a compiler from Atmel.

[salkinium]

In CircleCI, we use the AVR GCC from Ubuntu 16.04, which is not a compiler from Atmel.

My hope was that by using the canonical compiler from Atmel we could avoid issues with the different custom compiled avr-gcc packages by different Linux distributions. However, that requires the end user to actually install the (outdated) Atmel avr-gcc. To my limited experience with our linux devs, that's not what happens, they just install whatever their distributions package manager installs, and so we should also just use the latest avr-gcc from upstream.

The question is really about device coverage, because the upstream avr-gcc fails to compile/assemble for more AVR devices than the Atmel avr-gcc (I assume they don't upstream their changes).
I'd be ok with using the latest upstream avr-gcc, either precompiled from the distribution or shipped as a Docker container.

To be honest, I don't really care that much about AVRs anymore, since Cortex-M is just waaaay less of a hassle in the long run. Just thinking about the hacks required to access constant data in flash on AVRs makes me cringe.

[strongly-typed]

Yes, I don't care much about AVRs as well. Their technology is limited and cumbersome sometimes. The only benefit is cheap and widespread Arduino hardware. But the blue pill and Nucleos are becoming a better alternative.

We could use Github releases to provide the tar ball here.

CircleCI successfully built the artifact yesterday for me. The last step would be to publish this artifact to Github automatically. Then, TravisCI (and any user) could rely on this toolchain.

I have to admit that this is more about demonstrating methods on how to streamline such a process. I really don't care much about AVRs.

[strongly-typed]

So, this now seems to work: TravisCI now uses the latest Atmel toolchain compiled on CircleCI.

What about the boost.tar.bz2?

[strongly-typed]

What about the boost.tar.bz2?

Friendly ping.

[salkinium]

What about the boost.tar.bz2?

Also built and hosted on my private server, but didn't document how. I think it would be good to create the shell script /tools/build_boost.sh to automatically build this from source, then host it on GitHub as a resource.

Maybe boost should be replaced with the C++ standard library? It is mostly used for things like threading and IO which should by now be implemented natively in the stdlib++.

[salkinium]

The only dependence we now have on hosted is Boost.Asio, which exists also as a standalone version:
https://think-async.com/Asio/AsioStandalone (via #322 (comment)).