Build Refactoring and Updates

[ginty]

This update does the following:

• Refactors the Travis build script following a template I found, which I think makes it easier to follow and extend in future
• The Linux CLI can now be built as a static (fully self contained) binary
• Adds a deploy hook which should build release packages for Windows and Linux containing the CLI and post to Github

I'll generate a tag and test run the last point once this lands in master.

This should be in good shape now to add in a Python package build and deploy (once we work out how to do that!).

It doesn't seem like you can build a static Windows binary in the same way, but what's there now should be what we've always had and I assume it still works.

If you want to generate a static binary in your dev environment, these are the steps:

• install musl-tools (e.g. apt-get install musl-tools)
• rustup target install x86_64-unknown-linux-musl (only need to do this once)
• cargo build --target x86_64-unknown-linux-musl --release --workspace --bins

[coreyeng]

Looks good! Good find on the Travis template too. Does this build the pyapi in the executable as well, or just the CLI/origen?

[ginty]

It doesn't build the pyapi in the release package currently, though it would be easy to add it. I wasn't sure if we would need to make that available for download directly, or if it would just get wrapped up in a Python gem (whatever that's called).

One thing I did notice is that for the .so you can't make it fully self/contained and Linux-agnostic like you can with a binary, I think that's just the nature of a .so library.

That library that I got the script template from actually provided a way to build for all different types of Linux/OSX/Windows etc, however it used docker images for each one, and those didn't come with Python installed, so I bailed on that. Probably you can make the docker image install Python, but I don't really know how to use it and it seemed like potentially opening up a can of worms.

Right now my fingers are basically crossed that a .so built on Travis will just work on RHEL7. RHEL6 I think for sure will not, but I think we should just move on with the rest of the world and say RHEL7 is the minimum version for O2. It should be good though having a universal CLI at least which can help to guide the user through install/environment issues.