Add AppVeyor file for CI

[mrexodia]

This builds with mingw-w64 on Windows and whatever make takes as the default on Ubuntu. Additionally artifacts are created so if you add your project to AppVeyor you can provide an automatic download link for the latest commit hash.

See https://www.appveyor.com/docs/

[Alcaro]

Adding a CI to Flips certainly is a valid proposal.

But while this is a good start, it needs some more work.

To start with, that 'version: 1.40.{build}' key looks scary. The more places the version number exists, the higher risk I forget updating one of them. Can it be autogenerated? If no, how much would break if it's deleted, or replaced with appv.{build}?

Second, and more important, the official builds use a quite aggressive set of build options, driven by make.sh (or, for the Windows build, make-maintainer.sh). If the CI should provide binaries, it must use the full set of compile flags, including PGO; providing semi-official binaries with suboptimal optimizations would just confuse people. This is best done by ignoring the Windows images and installing Wine in the CI, and editing make-maintainer.sh a little. (Alternatively, if the CI should not provide binaries but only ensure it compiles cleanly, that's fine too.)

I'll try to find some time to implement the above in the upcoming week, if you don't do it first.

[mrexodia]

In general my approach is that any ci is better than no ci. I just created some basic script with artifacts since I didn’t think the optimizations do much.

The version can be {build}, it’s just what’s shown in the web interface and it will increase for every build.

If you say those optimizations are important I’ll just remove the artifacts. But I recommend keeping the windows machine, just to check if it builds there.

On Mon, 29 Apr 2019 at 00:38, Alcaro notifications@github.com wrote:

Adding a CI to Flips certainly is a valid proposal.

But while this is a good start, it needs some more work.

To start with, that 'version: 1.40.{build}' key looks scary. The more places the version number exists, the higher risk I forget updating one of them. Can it be autogenerated? If no, how much would break if it's deleted, or replaced with appv.{build}?

Second, and more important, the official builds use a quite aggressive set of build options, driven by make.sh (or, for the Windows build, make-maintainer.sh). If the CI should provide binaries, it must use the full set of compile flags, including PGO; providing semi-official binaries with suboptimal optimizations would just confuse people. This is best done by ignoring the Windows images and installing Wine in the CI, and editing make-maintainer.sh a little. (Alternatively, if the CI should not provide binaries but only ensure it compiles cleanly, that's fine too.)

I'll try to find some time to implement the above in the upcoming week, if you don't do it first.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Alcaro/Flips/pull/19#issuecomment-487421449, or mute the thread https://github.com/notifications/unsubscribe-auth/AASYFGMCTGJW6OVMWCB5AXLPSYROFANCNFSM4HI7D4GQ .

[mrexodia]

I synced with the latest master and removed all artifacts. I tried to get the other scripts to work for a while, but that Ubuntu doesn't seem to want to install Wine so I gave up :smile:

Also cleaned up the version.

[Alcaro]

Yeah, good enough, at least for now. I'll see if I can get it to build properly later.

If I do, building under mingw twice is a waste of time. But I could repurpose the VS box to build under MSVC instead, so I don't accidentally use some GCC extension.

Any CI is indeed better than no CI. It's debatable how much, but it is an improvement.

[Alcaro]

As for the optimizations, Flips has been downloaded at least 200000 times. Small improvement (PGO makes it ~2% faster) times 200000 users is a quite considerable amount.