[tests] add hxBitcoin library for third-party CI tests

[nadako]

This new cryptography/cryptocurrency library https://github.com/cbatson/hxBitcoin seems to have extensive tests that IMO we should add to our CI tests as it would help preventing regressions wrt optimizations like const propagation and whatnot.

[Simn]

Why is this not a pull request? ;)

[nadako]

i was hoping @andyli could somehow add this quickly before I start looking into it :)

[Simn]

Is there still no way to make travis trigger third party builds?

[waneck]

I could configure the build servers to trigger a travis build. I'd need a travis token and I'm not sure how this will actually work - will we trigger the travis build at hxBitcoin? Or will we trigger the travis build on a fork of it?

[waneck]

We could maybe setup a (low security) github user which will fork all projects we want to trigger a build. This way the build servers can automatically pull from upstream and trigger the travis build on the latest Haxe.

[andyli]

I would suggest hxBitcoin (and other 3rd party libs) to have its own travis build because that scales better with increasing number of libs. If we use our HaxeFoundation acc (or a dedicated acc), the number of concurrent builds is very limited.

[waneck]

I wouldn't mind the builds being slow if we used a dedicated account for that

[Simn]

The problem with them having their own travis is still that we cannot ping it to run. They need their own travis too though because otherwise we end up in a situation like with the OpenFL tests where they kept breaking their stuff and we were the only ones to notice.

[waneck]

We can ping them to run again with the travis api. I can trigger a travis
rebuild from the build servers. Also the nice thing about this is that we
don't have to rebuild haxe from scratch - we can use the freshly built
binary
We can also avoid getting pinged when a lib breaks their own stuff by using
a fork and only merging from upstream occasionally - perhaps with a pull
request

[Simn]

Ah, if that's possible now then it's a good solution.

[Simn]

"Your test run exceeded 50 minutes."

Oh dear... :)

[cbatson]

Yeah. :-) The tests run really slow on Neko on that system for some reason. I haven't timed it, but I don't think it takes that long on my aging local PC.

And that was just one of several unanticipated adventures along the way. Here's another fun one you'll appreciate: https://chuckbatson.wordpress.com/2014/12/20/gcc-compiler-bug-broke-my-haxe-code/

It is done, at least for Linux + hxcpp. Hope to add more targets & platforms to the automated process later. (I run them manually on all platforms before a release.)

[Simn]

I see that you're running your tests with Haxe stable. That doesn't really help us much, hmm...

[cbatson]

I'll add a variation that runs against development Haxe. Is cloning from git and building the best way to do that, or is there another preferred way?

[cbatson]

Please take a look now; I have a couple jobs in the Travis matrix using Haxe from git.

Will this work for your needs?

[Simn]

This fell under the radar completely so we might as well close it now. Sorry about that.