freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] buiding ttfautohint with cmake?


From: Martin Gieseking
Subject: Re: [ft-devel] buiding ttfautohint with cmake?
Date: Thu, 7 Dec 2017 23:18:02 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

Hello Cosmimo,

I'm also interested in a shared library of ttfautohint and played around
with the build system. The attached patch modifies the autotool scripts
so that public static and shared libraries are built and installed.
When using MSYS2/MinGW64 on Windows, I get a working DLL. It doesn't
contain harfbuzz and freetype, though. They must be linked separately to
the target applications. However, it shouldn't be too complicated to
build a DLL of ttfautohint that statically links all dependencies, e.g.
using dlltool.

Martin


Am 07.12.2017 um 16:51 schrieb Cosimo Lupo:
> Thanks Werner,
> 
> 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
> operating systems.
> 
> 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
> ttfautohint executable.
> 
> If you have any tips, please let me know, thank you!
> 
> Cosimo
> 
> On Thu, Dec 7, 2017 at 2:05 PM Werner LEMBERG <address@hidden
> <mailto:address@hidden>> wrote:
> 
> 
>     Hello Cosmimo,
> 
> 
>     > 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.  [...]
> 
>     OK.
> 
>     > 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
>     by myself.
> 
>     > 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
>     ttfautohint requires:
> 
>       dirname
>       fcntl-h
>       getopt-gnu
>       git-version-gen       (only necessary for the ttfautohint binary)
>       isatty                (ditto)
>       memmem-simple
>       progname              (ditto)
>       stdarg
>       stdbool
>       stdint
>       std-gnu11
>       strerror_r-posix
>       strndup
>       strtok_r
>       strtoull
>       vasprintf
> 
>     Please consult the gnulib git repository for more information on the
>     used modules.
> 
>     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.
> 
> 
>         Werner
> 
> -- 
> Cosimo Lupo
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 

Attachment: ttfautohint-lib.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]