|
From: | Cosimo Lupo |
Subject: | Re: [ft-devel] buiding ttfautohint with cmake? |
Date: | Fri, 08 Dec 2017 21:44:51 +0000 |
Thanks Martin! It works well :)Werner, would it be possible to merge this patch upstream, so that I can use it without having to apply this downstream?I think it would be useful for others as well to be able to build a shared library for ttfautohint.ThanksCosimoOn Fri, Dec 8, 2017 at 7:55 AM Martin Gieseking <address@hidden> wrote:Am 08.12.2017 um 02:27 schrieb Cosimo Lupo:
> P.S. It’s Cosimo btw ;)
Oops, just noticed the typo. Sorry for that. It wasn't intentional.
Let me know if you have any issues with the the build modifications.
Martin
>
> Il 7 dic 2017, 22:18 +0000, Martin Gieseking <address@hidden>,
> ha scritto:
>> 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
>>>
>>
--Cosimo Lupo
[Prev in Thread] | Current Thread | [Next in Thread] |