Add automated build checks

[TheSlowGrowth]

In addition to the automated style checks and doc deployment (see #35), the build could be checked as well.

The key will be to install arm-gcc-none-eabi on the travis VM. I'll have a look how that could work.

[stephenhensley]

You might be able to wget a binary package from Arm's toolchain page since I think it contains binutils and everything else it would need.

I know STM32Duino has a pretty robust CI setup, but it looks like they're using Github Actions now with a few extra tools for dealing with all of the Arduino-building.

[TheSlowGrowth]

Build job seems to work.

I'd like to add ./rebuild_examples.sh but that relies on libdaisy being installed in the parent directory. We'd have to manually clone the repo during the build process, but how do we then specify the specific commit to checkout? My solution would be to add libdaisy as a submodule, but that has its own drawbacks...

[stephenhensley]

sweet!

Yeah, the examples tie in with #25 anyway. I'm going to move those to DaisyExamples since that already has libdaisy and DaisySP as submodules, and then we can end up setting up the CI there to do a rebuild_all.sh check.

[stephenhensley]

and at some point it might be nice to add some non-libdaisy tests so that we can just get the daisyp modules compiling since some of the header only files won't throw errors until a source using it is compiled.

Though, I'll have to toy with how small of an arm-none-eabi project I can get going, because I don't want to drag in a million files for tests..

[stephenhensley]

Alright, this appears to be working. It does fail to deploy, but I still haven't set up the electro-smith github page so that's to be expected.

I'm going to leave this open until it's passing.

[stephenhensley]

Alright, deployed and all passing

[TheSlowGrowth]

Great!

A little afterthought: I agree it is a good idea to keep this repo free from dependencies. However, moving the examples to a separate repo has two disadvantages:

1. You'll somehow have to compile the header-only modules, as you mentioned before. That means you'll manually have to setup some C++ file where EACH FUNCTION in this module is called at least once so that all of them are actually compiled. This basically means to build another "dumb" example for each header-only module.
2. Having the examples here means that you'll see if they work, before merging a PR. As example and module go hand in hand, I think this is a very important step. Otherwise the example and the module become kind of decoupled and a change to the module will have to consist of two separate PR in two separate repos that have to be synchronized somehow during the review process.

[stephenhensley]

@TheSlowGrowth

Agreed, just after I finished getting everything running with CI I had considered the same disadvantage.

The cost of maintaining a separate no_examples branch for the ArduinoDaisySP library is beginning to seem much less than having to add/maintain a load of tests specifically for daisysp.

Still, though, we're not testing the DaisySP examples on PR since we would need to have libdaisy to do that. So I'm still deciding the best solution to that problem.

---

Also, worth mentioning that we do have a Daisy slack group if you're interested in that. For now it's mostly been for announcements, and trouble shooting. But its a good place to discuss things that don't necessarily fall into issue-territory.