I looked at the gnulib docs but honestly it looks a bit complicated..
I think that, for the beginning, I will compile the Windows DLL with
the mingw-w64 toolchain in an msys2 environment.
I think that should work fine, even from the official MSVC-compiled
cpython distribution, because I'm not planning to make a python
extension module (i.e. shared object that calls into the Python C API
and requires to link with the python library, thus needs to be compiled
with the same compiler as python itself), but just a shared library
independent from python that is dynamically loaded at runtime via dlopen
or LoadLibrary by ctypes or cffi.
This way I can use the normal autotools build system on all three
I just need to figure out how to create a shared libttfautohint.so, as
the current setup normally only creates a static library embedded in the
If you have any tips, please let me know, thank you!
On Thu, Dec 7, 2017 at 2:05 PM Werner LEMBERG <address@hidden
I would like to make a Python wrapper for ttfautohint, [...] I want
to build a shared library (.so, .dll, .dylib) and call that from
Python using either ctypes or better CFFI. [...]
Now, freetype and harfbuzz both support cmake as an alternative to
./configure && make stuff. That's great.
Note, however, that FreeType's cmake stuff is contributed code. Since
I dislike cmake I haven't enough experience to handle potential issues
From a cursory look at the ttfautohint source, I see that it depends
on gnulib, which looks like it's closely tied with the autotools...
I couldn't find any cmake projects using gnulib on the net.
This is probably correct. Maybe a cmake e-mail list or forum can give
you more advice.
For those of you who are more knowledgeable about this, how
difficult would it be to adapt the current autotools-based build
system of ttfautohint to use cmake, for example?
In file `bootstrap.conf' you can find the list of gnulib modules that
git-version-gen (only necessary for the ttfautohint binary)
Please consult the gnulib git repository for more information on the
The idea of gnulib is that it only provides replacement code if the
host's functionality is either missing, incomplete, or buggy. These
tests are implemented as M4, to be automatically integrated into
automake and/or autoconf.
It's probably easiest if you find, say, BSD replacement code for the
above functionality; cmake then could simply compile and link to it if
it is missing.
Freetype-devel mailing list