search

silnrsi / graphite

Graphite is a "smart font" system developed specifically to handle the complexities of lesser-known languages of the world.
http://graphite.sil.org/
Other
146 stars 44 forks source link

Correct relative library path #45

Closed bgermann closed 3 years ago

bgermann commented 6 years ago

This fixes the issue introduced in d9be1d805.

tim-eves commented 6 years ago

I'm coming to the conclusion that this is a packaging problem with the wheel and that it should place the built so/dll in next to the init.py. Then the entire block starting if libpath is None could be removed and we can rely on ctypes.util.find_library to locate the so/dll for us.

bgermann commented 6 years ago

ctypes' and ctypes.util.find_library's search paths do not contain the module's path. So even if we moved the library it would still not find it. Please merge.

bgermann commented 5 years ago

It would have been great if you had put this in the 1.3.13 release. Will it be included in the next release?

bgermann commented 5 years ago

@mhosken Can you pleasetake care of this?

bgermann commented 5 years ago

As nobody seems to care about this issue, I will explain it more in-depth. If scikit-build is available at build time the Python module is built with it, which includes building the graphite2 library via cmake. The resulting directory structure does not fit with the search path for the library that is part of the module.

This is not important for systems where graphite2 is installed in the system's library path. But it is very important for other systems, e.g. for Windows. At the moment there is no good user story for people wanting to use the graphite2 Python module on Windows. This also impacts Graide. If there was a wheel on PyPI including the built library the user story would improve a lot. I am willing to publish such wheels on PyPI starting with the next release given that this PR is merged.

mgood7123 commented 3 years ago

applied in https://github.com/silnrsi/graphite/pull/69