Freetype library name on windows and Mac OS X about freetype-py HOT 18 OPEN

But ctype is supposed to resolve that more or less automatically, no ?
I'm not familiar with naming schemes and I always wondered what the 6 stands for ?

from freetype-py.

I think the 6 came from when freetype got adopted by the Xfree86/Xorg folks - every major library version was 6. From X11 R6. I think ctypes deals with the dll and possibly even the dylib part, but not the rest. SharpFont (c# binding of freetype, mostly windows centric) distributes 'freetype6.dll', mingw compiled freetype is named "libfreetype-6.dll'.

from freetype-py.

freetype from homebrew (OSX) is named without the 6 indeed. But we can change the default to the one with the 6 and fall back to the one without if not found.

from freetype-py.

It's a bit annoying that you get different file names depending on the build system you use... would it make sense to instead look for *freetype*(so|dylib|dll)* (extension depending on platform)?

from freetype-py.

For the embedded library of course it doesn’t matter the filename nor the extension, as we load it with its relative path and that is hard-coded and known in advance.

from freetype-py.

@madig You mean testing all combinations? Because I'm not sure ctypes offer any useful search patterns.

from freetype-py.

One could go though all combinations and feed them to ctypes. But maybe the pre-built binaries make that superfluous.

from freetype-py.

But if people install without pre-built binaires, this is still a problem.

from freetype-py.

Yes, but maybe people won't do that as often with bundled binaries :) Something for another PR.

from freetype-py.

Yes. @HinTak Do you think it still worth investigating?

from freetype-py.

from freetype-py.

I apologize if I am missing some existing way to do this, but would allowing the library name and path to be specified, by environment variables or some such be a possible solution to @HinTak's question? Something like (in raw.py):

filename = os.getenv("FREETYPEPY_FT_LIBPATH")

if not filename:
    ... current logic to find lib/set value of filename which is eventually passed to ctypes.CDLL() ...

It seems to me that something like this could be useful to anyone wishing to use freetype-py with a custom FreeType library that is not necessarily system-installed, not in the pre-set search locations, or uses a different filename from what freetype-py expects.

from freetype-py.

Location is a different thing - freetype-py itself (or rather, the underlying ctype package) already let you change location of look-up by the corresponding OS mechanisms: on Linux/mac os x, via LD_LIBRARY_PATH, and for windows, just PATH , I think. This issue is about variation in the file naming and extensions: dll vs so vs dylib, and the 6 and another space or dash before and after.

from freetype-py.

I should clarify: I was thinking FREETYPEPY_FT_LIBPATH would be used to supply a complete path (including filename) to a specific freetype library file. This would accommodate a non-standard location and non-standard file naming, which happens to be my particular use case. But maybe that's too limited for general use.

from freetype-py.

@josh95117 The idea would be worth to be investigated. But I'm afraid people will set if and forget they've set it at some point. If we go in this direction, we would need a specific error message saying the filename provided by the env variable was not found.

But in the end, we only have to test a moderate number of standard combinations so maybe this the
most simple way to do it. And we can also use @josh95117 proposal for exotic name and location.

What do you think?

from freetype-py.

@rougier yes, I understand the concern about setting the environment variable and then forgetting about it. I guess it wouldn't be too hard to put a check for file existence in there.

But as I think more about this, I wonder if this is really a good way to solve the problem. As @HinTak mentions, the "-6", ".6" naming variations are common with different build systems. It seems like an unnecessary burden to require an environment variable for those scenarios (assuming the library eventually ends up in a standard location). It might be better to try to improve the library-finding logic to accommodate those names.

I'll try to do some work on this and do a PR with some actual implementations for people to critique, not just hypotheticals :-)

from freetype-py.

My idea was to use the env variable (whatever the name) to test for a specific places. As the library is, there is no simple way to use another freetype but the one found.

from freetype-py.

OK...I spent a little time studying ctypes.util.find_library() and wrote some code to do similar things, but in a more flexible way and geared specifically toward finding FreeType libraries (using a simple regex, which find_library() does not support). I'll commit once I've had a chance to test it more.

from freetype-py.