I would like to make a Python wrapper for ttfautohint, to use it for our fontmake
font building pipeline.
I don't want to call the native ttfautohint executable as a subprocess. I want to build a shared library (.so, .dll, .dylib) and call that from Python using either ctypes or better CFFI
. And I want to be able to simply `pip install ttfautohint`, or add "ttfautohint" to the installation requirements of my python libraries and have it "just work (TM)".
So, this library should be self-contained. I will have to build static libraries for harfbuzz and freetype and embed them in it. I don't want to dynamically link to the system libraries because they are outdated, and I don't want to rely on native package managers like apt or brew. Just pure Python with a setup.py, no native dependencies besides python itself and a C/C++ compiler.
And this build system should not rely on the presence of bash, make, autotools and the rest Unix tools, because I want a single command that I can call from my setup.py script that builds the ttfautohint shared library for all the three main desktop platforms (Mac, Linux and Windows), using the same compiler toolchain used to build python itself -- which on Windows is MSVC.
Now, freetype and harfbuzz both support cmake as an alternative to ./configure && make stuff. That's great.
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.
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?
I say cmake because both freetype and harfbuzz use it already, but maybe you have other suggestions?
Thank you in advance!