Bring up continuous build + dist

[jpd236]

I've got Travis and AppVeyor builds up and running on my fork. Here's the config:

jpd236@a3e22b4

(I can send a PR once the fix-compile branch is merged, as this is dependent on it)

Here's the build logs for Travis (Mac): https://travis-ci.org/jpd236/xword/builds/170340977
And for AppVeyor (Windows): https://ci.appveyor.com/project/jpd236/xword/build/34
And an example GitHub release: https://github.com/jpd236/xword/releases/tag/0.6.2-ci-alpha1

For both Mac and Windows, this config will build wxWidgets 3.1.0 (caching the build for future use) with the wxAUI patch from the xword repo and build both the Debug and Release configurations of the app. The dist step is kept simple for now since the existing dist scripts are Windows/sourceforge specific; we just zip the output files and upload the resulting artifact to GitHub Releases for any tagged build.

Here's what I think remains for this to be fully complete:

• Bring up the builds in mrichards42/xword. Once the configs/scripts are merged in, you'd need to enable Travis/AppVeyor on the project, generate GitHub API keys with public_repo access for each of them, encrypt them, and update the config files with the new api_key under the deploy: section. My suggestion would be to create a new machine user account and an API key for each service, but you could also generate API keys from your GitHub account directly; either way.
• Bring up a Linux build on Travis. I took a quick look at this but didn't find a simple way to make this work. Some issues I found: there's no Linux build of premake4 in the xword repo; Linux gcc seems to behave differently and doesn't compile XWord out of the box due to import/namespace issues; Travis only has 64-bit Linux images but the build seems to be 32-bit.
• Build out the rest of the dist/ process. The zip files can be unpacked and used but aren't a complete distribution.

If I can be of more help here, do let me know. Otherwise, I think these configs are about as much as I can contribute at this point.

[jpd236]

One other thing to look into as part of the dist process: Unlike svn, git doesn't support tracking of file modification times. This breaks the py2lua generation for the wxFB.lua scripts, because that process checks the mtime of the .py file and compares it to the time listed in the wxFB.lua file; however, a new git clone will always lead to the .py file's mtime being newer than what's written in wxFB.lua. We'd need another approach in git to make this work.

[mrichards42]

It's definitely annoying that after a fresh checkout the wxFB.lua files are regenerated, but it isn't a show-stopper, since the distribution won't include py2lua, just the (updated) wxFB.lua files themselves.

Probably better to just do an md5 of the python wxFB file or something simple like that.

[jpd236]

This is essentially done; all the changes have been checked in for a functional continuous build and dist for Windows and Mac. (I have a WIP for Linux, but it has a fair number of bugs to be hammered out to even have basic functionality, so I'd consider that separate).

You'd still need to get Travis CI up and running in the master repository to enable Mac builds, though. I think this should be fairly straightforward since the .travis.yml file is checked in already, but would be happy to help.

The other option now would be to try to consolidate to a single CI infrastructure, which has become a theoretical option since this was effort was all started. AppVeyor does have Mac/Linux images, and Travis has Windows images. But the AppVeyor Mac images have a newer version of Xcode that would require a new premake5 version to fix (see premake4.lua's note), and the Travis Windows images are considered experimental and lacking much of the niceties that the AppVeyor image has, including VS 2013.