QT6 build of ftinspect bit-rotten? (Re: skeletal makefile for ftinspect (Re: Future of autotools)

[Hin-Tak Leung]

 Btw, anybody done QT6 build of ftinspect lately?When I was writing the 
makefile, I had to install some qt5*-devel packages. I did some qt3/qt4 stuff a 
long time ago, so I kept those, but uninstalled most of qt5-dev stuff when I 
see qt6 being installed as part of half-yearly upgrade. I am on gnome, so kde 
stuff is really around for occasional curiosity. I just checked kde is still 
qt5... and only about 2 GUI applications I use depends on QT6 libraries. 
Anyway, I see some QT6 compatibility code in ftinspect, but they seem to have 
gotten bit-rotten / still WIP?

On Monday, 17 July 2023 at 00:22:05 BST, Hugh McMaster 
 wrote:  
 
 On Fri, 14 Jul 2023 at 00:49, suzuki toshiya wrote:

> The pkg-config interface should take care of everything easily. Debian and 
> Ubuntu have the relevant qt5 pkg-config files. Other distributions should too.

Does pkg-config give the information for the pathname of moc?
(the original question by Hin-Tak was asking about the
appropriate path to use moc command)

In my understanding, pkg-config is primarily designed to
provide the information to compile & link the libraries,
not designed to provide the information about the binary
executable commands.

Extra information beyond the standard prefix, sysconfdir, libdir etc. is 
package dependent.
In this case, Qt5Core.pc has a variable that provides the path to a directory 
containing binaries such as moc.


  

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[Hin-Tak Leung]

 Yes, the moc location on fedora 38 can be queried with:
pkg-config Qt5Core --variable=host_bins
If this works correctly on other systems, we should set 
MOC=`pkg-config Qt5Core --variable=host_bins`/moc
Or put PATH=${PATH}:`pkg-config Qt5Core --variable=host_bins` and MOC=moc ?
I am more inclined towards the former, few surprises.
On Monday, 17 July 2023 at 00:22:05 BST, Hugh McMaster 
 wrote:  
 
 On Fri, 14 Jul 2023 at 00:49, suzuki toshiya wrote:

> The pkg-config interface should take care of everything easily. Debian and 
> Ubuntu have the relevant qt5 pkg-config files. Other distributions should too.

Does pkg-config give the information for the pathname of moc?
(the original question by Hin-Tak was asking about the
appropriate path to use moc command)

In my understanding, pkg-config is primarily designed to
provide the information to compile & link the libraries,
not designed to provide the information about the binary
executable commands.

Extra information beyond the standard prefix, sysconfdir, libdir etc. is 
package dependent.
In this case, Qt5Core.pc has a variable that provides the path to a directory 
containing binaries such as moc.


  

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[Hugh McMaster]

On Fri, 14 Jul 2023 at 00:49, suzuki toshiya wrote:

> > The pkg-config interface should take care of everything easily. Debian
> and Ubuntu have the relevant qt5 pkg-config files. Other distributions
> should too.
>
> Does pkg-config give the information for the pathname of moc?
> (the original question by Hin-Tak was asking about the
> appropriate path to use moc command)
>
> In my understanding, pkg-config is primarily designed to
> provide the information to compile & link the libraries,
> not designed to provide the information about the binary
> executable commands.


Extra information beyond the standard prefix, sysconfdir, libdir etc. is
package dependent.

In this case, Qt5Core.pc has a variable that provides the path to a
directory containing binaries such as moc.

Re: Future of autotools

[Hin-Tak Leung]

 

On Friday, 14 July 2023 at 03:53:10 GMT+8, Werner LEMBERG  
wrote:
> Well, this is not how Meson support is currently set up in
`freetype-demos`: in `subprojects/freetype.wrap`, HEAD of FreeType's
> git repository is used.  This is absolutely necessary while developing
> since we regularly use new, not-yet-published features of FreeType in
> the demo programs.

> I don't mind if someone is going to modify the Meson stuff to move
> this requirement to an easy-to-use equivalent to `make devel`.  Then a
> standard Meson build could be against a system-installed FreeType
Okay, that's a fair point - features simultaneously getting added in both 
freetype2 and tested in freetype2-demos.
I probably will propose identifying some of the demos that don't (currently) 
needs private headers to have a "build-against-system" option. I mean cosmetic 
things like adding a toggle from one tool to another shouldn't need dev 
freetype.
Hin-Tak  

Re: Future of autotools

[Werner LEMBERG]

>> If we are going to overhaul the build system, I’ve long wanted to
>> have FreeType demos build as a separate package that links against
>> a system-installed FreeType library (not the source directory).
>
> I second that! I think only ttdebug definitely wants to link against
> freetype at the source/private header level.  You can see my
> skeletal makefile for ftinspect that it is using system freetype and
> that seems to work okay.  I think the majority of ftdemo can work
> against a stock system freetype+public header.

Well, this is not how Meson support is currently set up in
`freetype-demos`: in `subprojects/freetype.wrap`, HEAD of FreeType's
git repository is used.  This is absolutely necessary while developing
since we regularly use new, not-yet-published features of FreeType in
the demo programs.

I don't mind if someone is going to modify the Meson stuff to move
this requirement to an easy-to-use equivalent to `make devel`.  Then a
standard Meson build could be against a system-installed FreeType
library.


Werner

Re: Future of autotools

[Hin-Tak Leung]

 

On Thursday, 13 July 2023 at 22:46:38 GMT+8, Hugh McMaster 
 wrote:
> If we are going to overhaul the build system, I’ve long wanted to have 
> FreeType demos build as a separate package that links against a 
> system-installed FreeType library (not the source directory).
I second that! I think only ttdebug definitely wants to link against freetype 
at the source/private header level. You can see my skeletal makefile for 
ftinspect that it is using system freetype and that seems to work okay. I think 
the majority of ftdemo can work against a stock system freetype+public header.
> That’s how we detect python3 and librsvg (although I wish there were a 
> lighter library available). That said, there’s certainly an argument for 
> alternative approaches.
I don't know if rsvg does its own xml parsing or farms it off to libxml2 (for 
example), but the task of xml parsing itself is a library of its own in every 
programming language. The Java library for SVG, batik, is quite large too.
rsvg + cairo is about 7MB shared libraries; linking skia in adds about 25MB 
static - I suspect all the svg parsing in rsvg if done in static might come to 
a similar size. I have a small impression that skia-enabled ft2-demo is 
marginally faster than rsvg+cairo, but this is probably something for our GSoC 
students to measure/confirm/dispute :-).


  

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[suzuki toshiya]

The pkg-config interface should take care of everything easily. Debian and 
Ubuntu have the relevant qt5 pkg-config files. Other distributions should too.


Does pkg-config give the information for the pathname of moc?
(the original question by Hin-Tak was asking about the
appropriate path to use moc command)

In my understanding, pkg-config is primarily designed to
provide the information to compile & link the libraries,
not designed to provide the information about the binary
executable commands.

Regards,
mpsuzuki



On 2023/07/13 23:31, Hugh McMaster wrote:

On Thu, 13 Jul 2023 at 14:20, suzuki toshiya  wrote:
I would try to let AX_HAVE_QT() macro to find appropriate set:
https://www.gnu.org/software/autoconf-archive/ax_have_qt.html

In the case of Debian (and Ubuntu), qtchooser might be the unified
interface to switch 4, 5, and maybe 6 in future. It seems that
AX_HAVE_QT() does not check it, because the last update of AX_HAVE_QT
was 2014 X-p.

The pkg-config interface should take care of everything easily. Debian and 
Ubuntu have the relevant qt5 pkg-config files. Other distributions should too.

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[Hugh McMaster]

On Thu, 13 Jul 2023 at 14:20, suzuki toshiya  wrote:

> I would try to let AX_HAVE_QT() macro to find appropriate set:
>
> https://www.gnu.org/software/autoconf-archive/ax_have_qt.html
>
> In the case of Debian (and Ubuntu), qtchooser might be the unified
> interface to switch 4, 5, and maybe 6 in future. It seems that
> AX_HAVE_QT() does not check it, because the last update of AX_HAVE_QT
> was 2014 X-p.
>

The pkg-config interface should take care of everything easily. Debian and
Ubuntu have the relevant qt5 pkg-config files. Other distributions should
too.

Re: Future of autotools

[Hugh McMaster]

On Tue, 11 Jul 2023 at 19:26, suzuki toshiya wrote:

> Hi,
>
> In the conventional workflow, the source tree of the FreeType2 library
> has "./configure", but freetype-demos does not have. Just starting
> "make" with existing Makefile under "freetype-demos" carries the
> configured values from freetype directory.


If we are going to overhaul the build system, I’ve long wanted to have
FreeType demos build as a separate package that links against a
system-installed FreeType library (not the source directory).

I know the demos are intended to be used with the same version of FreeType,
so it could be a build dependency requirement to link against the same
version. This would avoid users linking against older versions.

The meson for the ftinspect
> wants to confirm additional libraries, like Qt5 (you can find the
> declaration of the dependency in src/ftinspect/meson.build).
>
> If somebody wants to try to make autotools to support the building
> of Qt5-based ftinspect, new configure should be added to freetype-demos,
> to check the availability of the extra libraries for ftinspect?



> Or, such check should be added to existing freetype/configure, even
> if libfreetype itself has no dependency with them?
>

That’s how we detect python3 and librsvg (although I wish there were a
lighter library available). That said, there’s certainly an argument for
alternative approaches.


> Regards,
> mpsuzuki
>

Re: Future of autotools

[Hugh McMaster]

Hi Werner,

On Tue, 11 Jul 2023 at 02:10, Werner LEMBERG wrote:

>
> >> If ftinspect and, potentially, other software is not going to be
> >> built via autotools, is there a case to move to another build
> >> system?
>
> Well, yes.  Meson will eventually become the main tool for building
> FreeType, I think (or rather, it definitely won't become CMake as the
> default).


This is good to know. I’ll start experimenting with meson to build the
Debian packages before making the switch.

However, cleaning up the build system was/is a GSoC
> project, so nobody else touched it in earnest.  In particular, I am
> not a specialist for Meson; additionally, Meson itself is still quite
> a moving target.
>

What functionality are you looking for? From my limited experience of
meson, it’s a bit clunky to get working, but once I’ve got the correct
commands everything seems to build correctly.

Hugh

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[suzuki toshiya]

I would try to let AX_HAVE_QT() macro to find appropriate set:
https://www.gnu.org/software/autoconf-archive/ax_have_qt.html

In the case of Debian (and Ubuntu), qtchooser might be the unified
interface to switch 4, 5, and maybe 6 in future. It seems that
AX_HAVE_QT() does not check it, because the last update of AX_HAVE_QT
was 2014 X-p.

Regards,
mpsuzuki

On 2023/07/13 12:19, Hin-Tak Leung wrote:

Besides the obvious (LDFLAGS and CXXFLAGS), I wonder what's correct way to 
detect the qt moc tool? It is

/usr/bin/moc-qt5
/usr/lib64/qt5/bin/moc
/usr/lib64/qt5/bin/moc-qt5

on my system (fedora 38). They are all the same. "/usr/lib64/qt5/bin/moc" is probably 
canonical, instead of "/usr/bin/moc-qt5" I put down in ftinspect.mk . Because

/usr/lib64/qt-3.3/bin/moc
/usr/lib64/qt4/bin/moc
/usr/lib64/qt5/bin/moc

are the other versions I have.

On Thursday, 13 July 2023 at 04:04:54 BST, suzuki toshiya 
 wrote:


Good, I was just trying to update configure.raw to add C++ version check & 
pkg-check for Qt5 :-)

Regards,
mpsuzuki


On 2023/07/13 11:30, Hin-Tak Leung wrote:

Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both 
to revise my makefile-fu, and perhaps as an educational tool for one of the 
gsoc people struggling with makefiles.

Here is a bare-minimum sketetal makefile for building ftinspect. It is written 
to be minimal, it builds, and the resulting binary seems to work, but since I 
have never used ftinspect, I don't know if the result does or does not work 
correctly.

Do "make -f ftinspect.mk", and if it finds all the QT5 bits on your system (a few 
variables towards the top, edit them yourself), it should just build ftinspect. There is a 
"make -f ftinpect.mk clean" target to clean up too.

The fragment is written with the idea that it can be eventually loadable by another. 
Current ft2-demo already do such for "./graph/rules.mk".

- ideally it should be "include"d somewhere in the middle of the main Makefile, 
like graph/rules.mk, and inherit the values of some of the variables (*CFLAGS).
- adjusting paths (adds in some  $(OBJ_DIR2)) and libtool adaptation (change 
the explicit $(CXX) comple/link actions with libtool $(COMPILE) abtractions).
- remove the "clean" target and merge its work with the main one.

I'd be interested to know if the build binary is broken, or seems to do the 
job, either way.

Have fun adapting it...




On Monday, 10 July 2023 at 13:05:58 BST, Hugh McMaster 
mailto:hugh.mcmas...@outlook.com>> wrote:


I've been preparing an update to the Debian package of FreeType and
realised ftinspect is limited to the meson build system only. Debian,
by default, has always used autotools.

There are three build systems currently available for use in FreeType:
autotools, cmake and meson. As I understand past discussions,
autotools is the default (and fully supported).

If ftinspect and, potentially, other software is not going to be built
via autotools, is there a case to move to another build system?

Hugh

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[Hin-Tak Leung]

 Besides the obvious (LDFLAGS and CXXFLAGS), I wonder what's correct way to 
detect the qt moc tool? It is 

/usr/bin/moc-qt5
/usr/lib64/qt5/bin/moc
/usr/lib64/qt5/bin/moc-qt5

on my system (fedora 38). They are all the same. "/usr/lib64/qt5/bin/moc" is 
probably canonical, instead of "/usr/bin/moc-qt5" I put down in ftinspect.mk . 
Because

/usr/lib64/qt-3.3/bin/moc
/usr/lib64/qt4/bin/moc
/usr/lib64/qt5/bin/moc

are the other versions I have.

 On Thursday, 13 July 2023 at 04:04:54 BST, suzuki toshiya 
 wrote:  
 
 Good, I was just trying to update configure.raw to add C++ version check & 
pkg-check for Qt5 :-)

Regards,
mpsuzuki


On 2023/07/13 11:30, Hin-Tak Leung wrote:
> Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both 
> to revise my makefile-fu, and perhaps as an educational tool for one of the 
> gsoc people struggling with makefiles.
> 
> Here is a bare-minimum sketetal makefile for building ftinspect. It is 
> written to be minimal, it builds, and the resulting binary seems to work, but 
> since I have never used ftinspect, I don't know if the result does or does 
> not work correctly.
> 
> Do "make -f ftinspect.mk", and if it finds all the QT5 bits on your system (a 
> few variables towards the top, edit them yourself), it should just build 
> ftinspect. There is a "make -f ftinpect.mk clean" target to clean up too.
> 
> The fragment is written with the idea that it can be eventually loadable by 
> another. Current ft2-demo already do such for "./graph/rules.mk".
> 
> - ideally it should be "include"d somewhere in the middle of the main 
> Makefile, like graph/rules.mk, and inherit the values of some of the 
> variables (*CFLAGS).
> - adjusting paths (adds in some  $(OBJ_DIR2)) and libtool adaptation (change 
> the explicit $(CXX) comple/link actions with libtool $(COMPILE) abtractions).
> - remove the "clean" target and merge its work with the main one.
> 
> I'd be interested to know if the build binary is broken, or seems to do the 
> job, either way.
> 
> Have fun adapting it...
> 
> 
> 
> 
> On Monday, 10 July 2023 at 13:05:58 BST, Hugh McMaster 
>  wrote:
> 
> 
> I've been preparing an update to the Debian package of FreeType and
> realised ftinspect is limited to the meson build system only. Debian,
> by default, has always used autotools.
> 
> There are three build systems currently available for use in FreeType:
> autotools, cmake and meson. As I understand past discussions,
> autotools is the default (and fully supported).
> 
> If ftinspect and, potentially, other software is not going to be built
> via autotools, is there a case to move to another build system?
> 
> Hugh
  

Re: skeletal makefile for ftinspect (Re: Future of autotools)

[suzuki toshiya]

Good, I was just trying to update configure.raw to add C++ version check & 
pkg-check for Qt5 :-)

Regards,
mpsuzuki


On 2023/07/13 11:30, Hin-Tak Leung wrote:

Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both 
to revise my makefile-fu, and perhaps as an educational tool for one of the 
gsoc people struggling with makefiles.

Here is a bare-minimum sketetal makefile for building ftinspect. It is written 
to be minimal, it builds, and the resulting binary seems to work, but since I 
have never used ftinspect, I don't know if the result does or does not work 
correctly.

Do "make -f ftinspect.mk", and if it finds all the QT5 bits on your system (a few 
variables towards the top, edit them yourself), it should just build ftinspect. There is a 
"make -f ftinpect.mk clean" target to clean up too.

The fragment is written with the idea that it can be eventually loadable by another. 
Current ft2-demo already do such for "./graph/rules.mk".

- ideally it should be "include"d somewhere in the middle of the main Makefile, 
like graph/rules.mk, and inherit the values of some of the variables (*CFLAGS).
- adjusting paths (adds in some  $(OBJ_DIR2)) and libtool adaptation (change 
the explicit $(CXX) comple/link actions with libtool $(COMPILE) abtractions).
- remove the "clean" target and merge its work with the main one.

I'd be interested to know if the build binary is broken, or seems to do the 
job, either way.

Have fun adapting it...




On Monday, 10 July 2023 at 13:05:58 BST, Hugh McMaster 
 wrote:


I've been preparing an update to the Debian package of FreeType and
realised ftinspect is limited to the meson build system only. Debian,
by default, has always used autotools.

There are three build systems currently available for use in FreeType:
autotools, cmake and meson. As I understand past discussions,
autotools is the default (and fully supported).

If ftinspect and, potentially, other software is not going to be built
via autotools, is there a case to move to another build system?

Hugh

skeletal makefile for ftinspect (Re: Future of autotools)

[Hin-Tak Leung]

Not really a big fan of cmake/qmake/meson, I thought I'll give it a try, both 
to revise my makefile-fu, and perhaps as an educational tool for one of the 
gsoc people struggling with makefiles.

Here is a bare-minimum sketetal makefile for building ftinspect. It is written 
to be minimal, it builds, and the resulting binary seems to work, but since I 
have never used ftinspect, I don't know if the result does or does not work 
correctly.

Do "make -f ftinspect.mk", and if it finds all the QT5 bits on your system (a 
few variables towards the top, edit them yourself), it should just build 
ftinspect. There is a "make -f ftinpect.mk clean" target to clean up too.

The fragment is written with the idea that it can be eventually loadable by 
another. Current ft2-demo already do such for "./graph/rules.mk".

- ideally it should be "include"d somewhere in the middle of the main Makefile, 
like graph/rules.mk, and inherit the values of some of the variables (*CFLAGS).
- adjusting paths (adds in some  $(OBJ_DIR2)) and libtool adaptation (change 
the explicit $(CXX) comple/link actions with libtool $(COMPILE) abtractions). 
- remove the "clean" target and merge its work with the main one.

I'd be interested to know if the build binary is broken, or seems to do the 
job, either way.

Have fun adapting it...




On Monday, 10 July 2023 at 13:05:58 BST, Hugh McMaster 
 wrote:


I've been preparing an update to the Debian package of FreeType and
realised ftinspect is limited to the meson build system only. Debian,
by default, has always used autotools.

There are three build systems currently available for use in FreeType:
autotools, cmake and meson. As I understand past discussions,
autotools is the default (and fully supported).

If ftinspect and, potentially, other software is not going to be built
via autotools, is there a case to move to another build system?

Hugh

ftinspect.mk
Description: application/wine-extension-mk

Re: Future of autotools

[Hin-Tak Leung]

 On Tuesday, 11 July 2023 at 17:27:02 GMT+8, suzuki toshiya 
 wrote:
 
> If somebody wants to try to make autotools to support the building
> of Qt5-based ftinspect, new configure should be added to freetype-demos,
> to check the availability of the extra libraries for ftinspect?
> Or, such check should be added to existing freetype/configure, even
> if libfreetype itself has no dependency with them?

This is definitely a "me too" moment. Am in the middle of ripping out the 
librsvg code and replacing it with skia in ftview/ftgrid, and rather annoyed 
that librsvg is detected in freetype2's configure rather than freetype2-demo's 
own. Freetype2 itself definitely has no dependency on librsvg and cairo!  

Re: Future of autotools

[suzuki toshiya]

Hi,

In the conventional workflow, the source tree of the FreeType2 library
has "./configure", but freetype-demos does not have. Just starting
"make" with existing Makefile under "freetype-demos" carries the
configured values from freetype directory. The meson for the ftinspect
wants to confirm additional libraries, like Qt5 (you can find the
declaration of the dependency in src/ftinspect/meson.build).

If somebody wants to try to make autotools to support the building
of Qt5-based ftinspect, new configure should be added to freetype-demos,
to check the availability of the extra libraries for ftinspect?
Or, such check should be added to existing freetype/configure, even
if libfreetype itself has no dependency with them?

Regards,
mpsuzuki


On 2023/07/11 1:10, Werner LEMBERG wrote:



If ftinspect and, potentially, other software is not going to be
built via autotools, is there a case to move to another build
system?


Well, yes.  Meson will eventually become the main tool for building
FreeType, I think (or rather, it definitely won't become CMake as the
default).  However, cleaning up the build system was/is a GSoC
project, so nobody else touched it in earnest.  In particular, I am
not a specialist for Meson; additionally, Meson itself is still quite
a moving target.


That's a bit unsatisfactory. Personally I only use the autotools/make
to build. Also as far as I know, last I heard there is(was?) a bug of
ttdebug being mis-built by meson - it is missing a -DUNIX or something
of that sort to control the command buffering.


Yep, https://gitlab.freedesktop.org/freetype/freetype-demos/-/issues/24


I sort of feel like raising it from time to time when the GSoC
students are updating the build system "have a look at fixing that
too..." but ultimately it sounds like dumping uninteresting/tedious
work on young people.


It seems so, unfortunately.


I think Werner would respond at some point writing "patches welcome"
for building ftinspect with autotools :-).


You are reading my mind :-)


 Werner

Re: Future of autotools

[Werner LEMBERG]

>> If ftinspect and, potentially, other software is not going to be
>> built via autotools, is there a case to move to another build
>> system?

Well, yes.  Meson will eventually become the main tool for building
FreeType, I think (or rather, it definitely won't become CMake as the
default).  However, cleaning up the build system was/is a GSoC
project, so nobody else touched it in earnest.  In particular, I am
not a specialist for Meson; additionally, Meson itself is still quite
a moving target.

> That's a bit unsatisfactory. Personally I only use the autotools/make
> to build. Also as far as I know, last I heard there is(was?) a bug of
> ttdebug being mis-built by meson - it is missing a -DUNIX or something
> of that sort to control the command buffering.

Yep, https://gitlab.freedesktop.org/freetype/freetype-demos/-/issues/24

> I sort of feel like raising it from time to time when the GSoC
> students are updating the build system "have a look at fixing that
> too..." but ultimately it sounds like dumping uninteresting/tedious
> work on young people.

It seems so, unfortunately.

> I think Werner would respond at some point writing "patches welcome"
> for building ftinspect with autotools :-).

You are reading my mind :-)


Werner

Re: Future of autotools

[Hin-Tak Leung]

 On Monday, 10 July 2023 at 20:05:58 GMT+8, Hugh McMaster 
 wrote:
 
 > I've been preparing an update to the Debian package of FreeType and
> realised ftinspect is limited to the meson build system only. Debian,
> by default, has always used autotools.

> There are three build systems currently available for use in FreeType:
> autotools, cmake and meson. As I understand past discussions,
> autotools is the default (and fully supported).

> If ftinspect and, potentially, other software is not going to be built
> via autotools, is there a case to move to another build system?

That's a bit unsatisfactory. Personally I only use the autotools/make to build. 
Also as far as I know, last I heard there is(was?) a bug of ttdebug being 
mis-built by meson - it is missing a -DUNIX or something of that sort to 
control the command buffering. I sort of feel like raising it from time to time 
when the GSoC students are updating the build system "have a look at fixing 
that too..." but ultimately it sounds like dumping uninteresting/tedious work 
on young people.
I think Werner would respond at some point writing "patches welcome" for 
building ftinspect with autotools :-).  

Future of autotools

[Hugh McMaster]

I've been preparing an update to the Debian package of FreeType and
realised ftinspect is limited to the meson build system only. Debian,
by default, has always used autotools.

There are three build systems currently available for use in FreeType:
autotools, cmake and meson. As I understand past discussions,
autotools is the default (and fully supported).

If ftinspect and, potentially, other software is not going to be built
via autotools, is there a case to move to another build system?

Hugh