Freetype library name on windows and Mac OS X

[HinTak]

Am a bit surprised that freetype-py looks only for freetype.dll or libfreetype.so.6 . It is usually freetype6.dll built from upstream 's visual studio project, and libfreetype.6.dylib in Mac OS X's convention.

[rougier]

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 ?

[HinTak]

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'.

[rougier]

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.

[madig]

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)?

[anthrotype]

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.

[rougier]

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

[madig]

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

[rougier]

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

[madig]

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

[rougier]

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

[HinTak]

Don't we want to look for libfreetype.dylib at least? We can probably forget about the libfreetype.6.dylib variant for the time being.

[josh95117]

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.

[HinTak]

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.

[josh95117]

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.

[rougier]

@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?

[josh95117]

@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 :-)

[rougier]

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.

[josh95117]

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.