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

[Cosimo Lupo]

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.

Thanks

Cosimo

On 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