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

[Werner LEMBERG]

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