This adds .appveyor.yml and a placeholder badge to the README. Builds take ~9 minutes, which is comparable to the Travis builds.

There are a couple of particular settings in the Appveyor config to make this work properly, namely "Custom configuration .yml file name" of .appveyor.yml and check "Skip branches without appveyor.yml.

I've marked this as work-in-progress because Appveyor needs to be officially set up for the python/cpython project so that the correct badge can be added to README.rst. We may also want to bikeshed about the version field, or other options that I haven't explored.

Example builds can be found at https://ci.appveyor.com/project/zware/cpython

The build might take 9 minutes but how long is it taking AppVeyor to get around to starting the build? Is that included in the 9 minutes? And I can add AppVeyor as a project to the repo when you want me to.

I didn't keep track of how long it took for builds to start, but it seemed to be fairly quick, not more than a minute or two.

Ready for you to add it whenever, as long as the 'ignore branches without appveyor.yml' setting is set.

It occurs to me that since AppVeyor actually lets you provide the full path to its configuration file, we could hide it away in .github instead of just UNIX-hiding it at toplevel.

FTR, the AppVeyor build of the latest commit (after changing the path to appveyor.yml in the project settings) started within a few seconds.

OK, AppVeyor is hooked up: https://ci.appveyor.com/api/projects/status/4mew1a93xdkbf5ua/branch/master?svg=true / https://ci.appveyor.com/project/python/cpython/branch/master

And let me know if I need to configure anything on AppVeyor itself; I literally just created the account and didn't touch a thing.

And as the badges show, the webhook is working.

@zware @zooba want to let me know what emails you have on AppVeyor so I can make you admins on the AppVeyor team account?

@brettcannon I'm not on AppVeyor. Will I need to be?

@zooba only if you want to administer the account through the web UI, otherwise you can just change the settings through the config file (and the account is set to email core-workflow-owner as a backup if I'm not available).

@brettcannon My AppVeyor account is linked to my GitHub account.

The only settings required should be setting the appveyor.yml path to .github/appveyor.yml and disallowing builds on branches that don't have appveyor.yml.

I tweaked the configuration to pull the YAML file from .github/appveyor.yml (I already checked the "require appveyor.yml" box yesterday to stop the failures). I also made you an admin on the team account.

So feel free to merge when you're ready!

I would prefer to see http://bugs.python.org/issue29530 fixed before add Appveyor, to not pollute pull requests with jobs known to fail, and no waste Appveyor resources. But it's up to you ;-)

By the way guys I will be working on cpython to work on some changes to a few things for cygwin to compile using the official cpython source code on 3.5, 3.6, and 3.7. Hopefully I can figure out cherry picking them for those versions as well. This should hopefully fix the main huge Python Fatal Errors on the TLS stuff on cygwin resulting in a core dump (Seems cygwin depends on TSS instead). When I get it working I will PR them. For now all my changes are to my own repo that has the python source code (sadly not a fork) But I probably should bring it up to the current stuff for 3.7 and also test on current 3.6, as well as current 3.5 branches by bringing the changes over to an fork.

Note: With this I might need to work on it for a few days on each of the 3 branches to ensure everything works like it should be.

Hopefully this is alright with you guys if I do this so that way it could help with the maintainers of cygwin not having to have people to maintain an slightly modified python that might be out of date from user needs. This might modify some of the build configure files as well to check for some header files that would normally be present in unix but not in cygwin making the build fail as well.

@AraHaan: "By the way guys I will be working on cpython to work on some changes to a few things for cygwin to compile using the official cpython source code on 3.5, 3.6, and 3.7. (...)"

Sorry, but this PR is the worst place to discuss Cygwin support: please open a new issue on bugs.python.org, or find the latest Cygwin issue and update it.

Cygwin is not currently officially supported by CPython, so changes should only be made in Python 3.7 (master branch). I'm neutral on supporting Cygwin. In the meanwhile, you can prepare a CPython fork, and then come back with atomic commits as PR? Since I expect many changes, you may also discuss Cygwin support on python-dev.

Ok I will do that in about a few hours when I get on my computer. However I can try to fork it on my iPhone to my GitHub for now. And some of the changes means a change from TLS to TSS. However for all the custom Cygwin changes to the C code would be offer blocked so that it is only active for Cygwin. I would also need some changes to some standard library files but those should be easy to track down and change. I can submit an PR and an patch file in bpo then as well.

Edit: I am now ready to push to my fork on my own cygwin 3.7 patch branch for building. Now it should be much easier for the cpython for cygwin maintainers to build by not having to mess with any of python's c code. However they might have to edit the 1st lines in some python scripts (2 or 3 of them) but otherwise it should be good to commit and merge into the main repo. Making an bpo issue with the patch file now as well.

Here is what is up with cygwin (I tested it with ./configure and did make, and should work if it was make installed as well):
Note: some modules could not be built on my end.

INFO: Could not locate ffi libs and/or headers

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_bz2                  _curses               _curses_panel
_dbm                  _gdbm                 _lzma
_sqlite3              _ssl                  _tkinter
nis                   ossaudiodev           readline
spwd                  zlib
To find the necessary bits, look in setup.py in detect_modules() for the module'
s name.

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
atexit                pwd                   time

Failed to build these modules:
_crypt                _ctypes

When I tested to see if python actually executes (TSS was the thing that python had to use to work on cygwin otherwise it could not allocate TLS entry because cygwin has bad TLS support anyway):

$ ./python.exe
Python 3.7.0a0 (default:4243df51fe43+, Mar  3 2017, 20:14:50)
[GCC 6.3.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

I'm only seeing one failure in test_re on AppVeyor which looks legitimate, so I'm going to go ahead and merge.

@brettcannon I can see on my AppVeyor profile that I'm supposed to be an administrator on the 'python' account, but can't figure out how to do anything with that role. I'm not sure if that's an issue with AppVeyor or me. Scratch that, I finally figured it out. I had to sign out, then sign in again and pick "python" as my github account. Very weird.