Windows

[montefra]

Re-Add support from windows executables and libraries.

I have no Window machine to test it.

We probably should enable appveyor to make sure that installation works.

[we should also enable travis CI for linux and mac]

[ericmandel]

@wjoye (DS9 author) has Windows capabilities. I'll see if I can test pyds9 on his setup next week.

[montefra]

That would be great. Thank you.

[ericmandel]

@montefra I can't test this until next week, because Bill Joye is away and I have no access to his machine. But, it looks like #45 is the test we want to make, right?

[montefra]

@ericmandel : no problem.

About #45: it's a problem at installation, also reported in #46. They all use anaconda and I don't remember seeing anything like that in standard python on my machine. I'll have to investigate.

[ericmandel]

OK, I'll try to help when Bill gets back and we have a Windows machine.

[montefra]

@ericmandel : I have enabled appveyor on your repo (been collaborator I can do it). However it is not triggered on PR, which is annoying. Unfortunately I cannot modify the settings of the repo so I'll have to ask you. Can you please go to settings and then either "webhooks" or "integration & services". Under one of the two you should see a page like this

Make sure that the Push and Pull Request are ticked. Thank you.

ps: I've added the travis logo on the README.

[ericmandel]

@montefra I can add a Webhook ... but what's the URL and what data format do you want?

[montefra]

The webhook should already be there. I can build using appveyor from your master

[ericmandel]

@montefra Hmmm ... here's what I see:

[montefra]

@ericmandel : ok. Thanks for checking. Then probably is better if you enable appveyor yourself for pyds9:

• https://ci.appveyor.com
• log in with github
• once you are logged in, click on "Projects" (in the bar on top of the page)
• click on "NEW PROJECT"
• from the list select pyds9. On the right you should see "ADD" button. Click it, but be careful to select the correct repository. They though that was a good idea to put the button on the opposite side of the page...
• you should see a page with the repo name and "LATEST BUILD HISTORY DEPLOYMENTS SETTINGS" buttons
• go back to github and then Settings -> webhooks. Now you should see on entry like: "https://ci.appveyor.com/api/github/webhook (pull_request and push)". If pull_request and push are in the string, then we are settled.

II'll see to get all directed to me with this

Thank you,

Fra

[ericmandel]

@montefra You should be all set now ... thanks, as always, for sending such explicit instructions, its very helpful.

[montefra]

@ericmandel: it looks like I am getting the the windows build a little step at a time. By default appveyor uses MinGW as environment. I had issues with running configure that I managed to solve using the latest config.guess and config.sub. Using those files did not break the linux and OSX build.

I would like to avoid having a version of xpa different from the official one and I don't know if the update I have done has any drawback for xpa itself. If you want I can make a PR on xpa with the new config.{guess,sub} and then you can decide what to do with it.

---

That said, now make works, but it fails with:

cextern\xpa\xpap.h(52) : fatal error C1083: Cannot open include file: 'sys/time.h': No such file or directory error: command 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\cl.exe' failed with exit status 2

I'll try to figure out how to get it to work. In the meanwhile if you have suggestions, do not restrain yourself :grin:.

Are you aware of XPA installation instructions for windows? I did some googling, but I haven't found anything.

[ericmandel]

@montefra You definitely need mingw or cygwin to build XPA under Windows -- that is where the unix-style include files, etc are to be found.

Mingw is smaller, but cygwin is a more sophisticated environment that Bill Joye uses to build DS9.

[ericmandel]

By the way, when you build under mingw or cygwin, the XPA configure script should sense this correctly and set the right compiler switches. It uses the cpp directives in the gcc of these compilers to make things work.

[montefra]

I have updated the appveyor.yml file according to astropy one, but didn't work. The last commit is trying to get cygwin according to the instructions here.

I can't say that I know what I am doing.

By the way, when you build under mingw or cygwin, the XPA configure script should sense this correctly and set the right compiler switches.

It did find mingw correctly, but I needed a newer autoconfig version. Once was complaining about not finding something (I think the platform) and I updated the config.guess. Then it complained about the msys part of the platform name and I fixed this with an updated version of config.sub.

[ericmandel]

@montefra Probably we should update the real XPA with those new versions of config.guess and config.sub. That has not been done in a decade ... did you get them from a standard site?

[montefra]

I got them from git.savanna.gnu.org, that I guess is the official gnu git repo. The two links are the file names in this comment.

This is the actual git repository: http://git.savannah.gnu.org/cgit/config.git/

[ericmandel]

OK, I updated XPA to use the same config files, so if you ever have to pull a new version of XPA, things will still work properly.

[montefra]

@ericmandel : if it's still running when you comes online, can you please stop/kill this build.

It would make sense that you make me admin for the pyds9 project on appveyor. This way I can kill builds when I screw up something and edit settings if needed. I'm trying to understand how to do it though. It seems that it's reasonably easy to make an existing user a collaborator with admin permissions, but it seems that it's non trivial to grant access to a single project

Here is some documentation and here is some more info

[ericmandel]

@montefra I'm not quite at work yet but ... on the pyds9 project, I changed the user role permissions so that users can do everything. Please see if that allows you to so what you need to do.

[ericmandel]

Also, it looks to me like all builds have completed or were cancelled. Is that correct?

[montefra]

I managed to stuck one of the build and appveyor has a timeout of 1hour... So the above request.

---

You need to make me part of your team. Go to the team page and add me (franz.bergesund at gmail.com) as collaborator with admin role.

BTW: I think that you don't want to make all users as admin. I'll revert them as soon as you grant me access.

[ericmandel]

OK, you are now a collaborator with admin role. I reverted the user permissions back to inherit. Let me know what else you need.

[montefra]

Perfect! that's it. Thank you.

I might need support with the compilation. I have no idea of how Windows and Cygwin work and I'm blindly testing options. I think that the setuptools is still got getting the Cygwin compiler.

[ericmandel]

@montefra Thinking more about this, you might want to use mingw instead of cygwin. Mingw is meant to be linked against windows programs ... I don't know how this is done with cygwin. So assuming the Python executable is a Windows executable (i.e. not built with cygwin), mingw probably is the correct choice.

[ericmandel]

The other thing that we might consider for Windows is supplying pre-built xpa.dll and xpans.exe files. That is, you build them once with mingw and supply them for Windows. This might be easier then trying to figure out how to build Windows binaries (dll and executable) dynamically withing the python environment.

[montefra]

@montefra Thinking more about this, you might want to use mingw instead of cygwin. Mingw is meant to be linked against windows programs ... I don't know how this is done with cygwin. So assuming the Python executable is a Windows executable (i.e. not built with cygwin), mingw probably is the correct choice.

I think that this is what happens already, but I am not that sure. Now I am tempted to ditch the current appveyor.yml file and see if this tutorial helps.

The other thing that we might consider for Windows is supplying pre-built xpa.dll and xpans.exe files. That is, you build them once with mingw and supply them for Windows. This might be easier then trying to figure out how to build Windows binaries (dll and executable) dynamically withing the python environment.

Even better: we can use appveyor to build wheels for windows: they are precompiled binaries with the whole package. But first I need to build it...

[ericmandel]

@montefra Bill Joye and I just built an xpans.dll and xpans.exe under cygwin on Windows10. We did this in the XPA directory by executing these commands:

./configure CC=i686-w64-mingw32-gcc AR=i686-w64-mingw32-ar --build=x86_64-unknown-mingw32 --without-tcl --prefix /home/joye/saods9 --exec-prefix /home/joye/saods9 --enable-shared --enable-symbols --with-x=disabled

make mingw-dll
make xpans

Obviously you'll want to change the prefix directory.

We then ran the xpans program under Windows, and took the generated dll and did this without error using Anaconda Python 2.7:

python
>>> import ctypes
>>> foo = ctypes.WinDLL("C:\\Users\\joye\\libxpa.dll")

Don't exactly know what to do after that ...

I put the xpans.exe and DLL files in: http://hea-www.cfa.harvard.edu/~eric/xpa_win10.tar.gz in case you want to try to use them. They are compiled for 32-bit Python.

Let me know if this helps.

[montefra]

@ericmandel : thank you for the test. Now I'm going on vacation for a few days. When I'll be back we'll think about how to proceed.

[montefra]

@ericmandel : This branch brought me more frustration than good. Since I should take care of the latest reports I am thinking to do the followin:

• create a new branch out of the current master
• cherry-pick the important commits of this branch (the first two should be the ones that I want )
• for windows only revert the installation mode to the old way (what you implemented)
• close this branch

If all go smoothly I can then fix the bugs reported recently and release a new version of pyds9.

[ericmandel]

@montefra Yes, you should do whatever helps you makes the most stable and easy-to-support version of pyds9. Once you have things settled, it might be worthwhile re-considering the use of Bill Joye's Windows DLL files for XPA. Although supplying binary files is not perfect, it will allow people to use pyds9 without having to install cygwin.

But for now, do what makes things easy and stable!