Updates to AppVeyor

[dra27]

Various things addressed:

• FlexDLL is now bootstrapped, rather than installed from a zip. Side-effect is that we can now only test 4.03.0+ (which is what was being tested already). Also reduces possible failure points (Alain's website, Chocolatey, etc.)
• The AppVeyor image already includes all the required Cygwin packages except the 64-bit gcc cross-compiler (I think it's a bit inconsistent that that package isn't installed, so I've raised https://github.com/appveyor/ci/issues/1816)
• The actual test spends most of its time upgrading Cygwin, I've added code which attempt to detect if this is strictly necessary (at the moment it definitely is). Having cygwin64-gcc-core preinstalled eliminates this, but I also suggested https://github.com/appveyor/ci/issues/1817 which we'd take advantage of if it's implemented.
• I've added a test which ensures that current OCaml trunk can be built with the new FlexDLL (it doesn't take that long, but it seemed unnecessary for the older versions?)

For testing, this branch was intentionally one commit behind master - but if you're happy, I'd do a rebase-and-merge.

[dra27]

The AppVeyor caches need clearing - once this has run through AppVeyor, I'll push again removing commit 7f35a36.

[dra27]

It does work: https://ci.appveyor.com/project/dra27/flexdll/build/1.0.26

[alainfrisch]

Wonderful.

I thought that the idea was to compile OCaml using the bootstrap procedure for flexdll on the tested revision, but that would take much longer than the 3-4 minutes reported on https://ci.appveyor.com/project/dra27/flexdll/build/1.0.26 . I'd expect any change to flexdll to trigger a full recompilation of OCaml+flexdll.

Also, any reason not to include OCaml 4.06?

[dra27]

I'm not particularly attached to how I ended up doing this, so feel very free to disagree!

So each job aims to have a working native-code compiler installed at C:\OCaml - those are now built using the bootstrap, but always the version that the submodule in OCaml has been configured with.

Every job therefore ensures that the new flexdll builds using that compiler.

For trunk (and 4.06 for now) there is then an additional test which just does make flexdll world (so doesn't re-run the whole of opt and opt.opt). It doesn't add that much to run this test for 4.03, 4.04 and 4.05, it just didn't seem as worthwhile to me. Most errors will show up quickly as ocamlrun won't build in make world but it also compiles the dynlink library, so it seems a reasonable confidence test that it's OK?

[dra27]

Note that the builds of course take longer if the OCaml branch itself is updated (so trunk and 4.06 are likely to do a full compiler build every time while we're in a release cycle).

[alainfrisch]

Ok, understood. Bootstrap of ocaml is not done using the tested revision of flexdll, but the one currently configured in the submodule of the ocaml branch. For 4.06 and trunk, and extra bootstrap (only "make world") is done again with the tested flexdll. It makes sense!

[alainfrisch]

Do you think there is value in keeping the history of commits, or should I just squash and merge?

[dra27]

Up to you - I personally prefer to keep separate commits as you never know what happens when bisecting in the future. Smaller diffs also allow for less detailed commit messages IMO, as it's clearer exactly what was being altered in small steps. Many other opinions are available!