dgasmith / gau2grid

Fast computation of a gaussian and its derivative on a grid.

https://gau2grid.readthedocs.io/en/latest/

BSD 3-Clause "New" or "Revised" License

29 stars 15 forks source link

various build fixes #37

Closed loriab closed 5 years ago

loriab commented 5 years ago

[x] fix memory pragmas for Intel compilers broken since #27
[x] install C lib to pygau2grid with
- extension py wants (not just copy C lib)
- no soversion extension
- gg (not libgg)
[x] fix windows install
[x] regen c code if py changes
[x] bump version in cmake to v1.3.1
[x] add cmake option NATIVE_PYTHON_INSTALL to do a python install of pygau2grid into current python site-packages rather than usual Linux prefixed installation. arrange for setup.py to use this rather than a semi-in-source install that was skipping necessary library renaming details for the compiled lib by skipping cmake installation.
[x] drop py27 support in testing (soft drop for pygau2grid)

loriab commented 5 years ago

This supercedes #36, being a coherently staged copy of same. And in response to your request for a direct cmake CI item, looks like appveyor fits the bill. Travis jobs haven't been starting -- travis reported this earlier in the week but thinks its resolved.

With the Intel fixes and the pygau2grid library naming changes, do you think a v1.3.1 is in order? Be sure to catch the CM version, too.

loriab commented 5 years ago

Ok, Mac c-b is happy with this PR (clang only since my Mac Intel license expired). Linux c-b is happy with this PR (Intel+GCC). Win appveyor is happy with this PR. I'd say good to go.

dgasmith commented 5 years ago

I needed to revert cgg = np.ctypeslib.load_library("libgg/gg", abs_path) to make things work on mac/travis. Was there a reason to switch?

codecov-io commented 5 years ago

Codecov Report

Merging #37 into master will decrease coverage by 7.53%. The diff coverage is 100%.

loriab commented 5 years ago

What problem did you run into that necessitated the gg-->libgg reversion? I ran it on Mac so should be fine. Current state is inconsistent b/c CMake still copying the plain gg file over. See Win that can't find SO any more.

Unless maybe you can't control the lib name build with build_ext? Looking at its source now. But I could see how that could break what I had.

Original libgg-->gg was trying to fix a problem where name turned out not to be the problem. So not vital in that sense (though I haven't tested the libgg). But looking at numpy and psi4, neither use the "lib" prefix in their compiled libs, so I stuck with "gg".

dgasmith commented 5 years ago

Just "gg" did not build cleanly on my mac or travis.

Appveyor should fail now if SO is not correctly linked. Do you know of a spot where NumPy uses this?