Dynamically discover path to XPA; favoring the host over the built-in

[jhunkeler]

In the interest of using a pre-existing XPA library this PR searches relative to sys.prefix first, and if no libxpa.(so|dylib|dll) is found, it falls back on the built-in version provided by pyds9.

I added in lib64 for CentOS systems, but search lib first because it's likely to be the "correct" hit. In Anaconda, for example, sys.prefix resolves to /path/to/anaconda/[env]/lib, but a system-installation of XPA on a 64-bit system could place libxpa in lib64. This also works well with normal virtualenv paths that have XPA installed directly into it.

[montefra]

@jhunkeler : thank you for the PR.

Astropy-helper provide a way to use a system library at build time and I plan to figure out how to use it (see issue #26).

Once that is done I'll come back here. However I'm not that sure about the part of favoring the system libxpa over the local one. pyds9 also builds xpans and installs it together with the python files. I have no idea if libxpla and xpans from different builds/versions can live together.

@ericmandel : any though?

[ericmandel]

@montefra @jhunkeler Yes, all versions 2.x of xpa over the past 20 years or so have been compatible with one another.

That said, isn't it true that pyds9 will have the latest version of xpa in it, since it's using xpa as a sub-module? The point is that for the past 5 or 6 years, all xpa changes have been compiler fixes and platform ports. So it may be better to compile the latest version in all cases ...

[jhunkeler]

@montefra Welcome. I noticed #26 but it had not been touched in a while so that's how this PR came about 😄

@ericmandel Yes, I'm pretty sure the ABI is solid for the XPA v2.x series. I didn't notice anything weird when I tried using libxpa from an external source.

Im pretty sure you'll need to update the submodule manually on your end every so often. Git submodules act like a symlink to a single commit, and do not pull the latest commit of a particular branch/tag when git submodule [init|update] is executed by the end-user.

[ericmandel]

@jhunkeler OK, thanks, I'm frankly ignorant about how git sub-modules work ...

[montefra]

@jhunkeler : #26 it hasn't been touched in way too much time. I plan to start working on it asap. I hope it's not too painful, as the astropy helper documentation sometimes doesn't help too much. Once it's done we can test how it works with conda.

A submodule points to a specific commit (in this case tags), not to the HEAD of a branch. The latter would be quite dangerous and prone to random errors. We you want to update the submodules, you cd into them, do:

• git fetch origin
• git checkout [whatever you want/need]
• go back to the parent repository and commit the changes. The next submodule [init|update] should pull all the new commit

[ericmandel]

@montefra thanks ... as usual.

The Debian requirement discussed in #26 is legitimate, so I'll let you get on with it, as you see fit.

[jhunkeler]

@montefra https://github.com/astropy/astropy/blob/ffc0a89b2c42fd440eb19bcb2f93db90cab3c98b/astropy/io/fits/setup_package.py#L13

This is an example of how Astropy builds cfitsio. If the user issues python setup.py install --use-system-libraries it simply skips over building the library and uses pkg-config (or whatever they've cooked up in their wrapper) to set CFLAGS, LDFLAGS, etc.

[montefra]

@jhunkeler : I know. However I need to check how it works for us. We use ctypes and I'm afraid that I have to explicitly import the libxpa{so,ddl} file.