freetype-devel
[Top][All Lists]
Advanced

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

Re: Build system considerations


From: Behdad Esfahbod
Subject: Re: Build system considerations
Date: Thu, 30 Apr 2020 10:35:19 -0700

Hi David,

Thanks for bringing this up.  I come from the GNOME camp.  My understanding is that meson is replacing autotools longterm, sidestepping attempts like cmake, the same way that git replaced CVS, sidestepping mercurial, bazaar, etc.

In the latest HarfBuzz release we added a meson build system.  Over the next few months I expect us to remove our cmake one and eventually the autotools one (which is the "official" one right now).

Hope that helps,
behdad

On Wed, Apr 29, 2020 at 5:34 PM David Turner <address@hidden> wrote:
Starting a thread here to discuss potential build system improvements for FreeType.

The current FreeType 2 build system has many flaws. To its credit, it was designed in a very different time, when things like CMake / Meson / Ninja/ Maven / GN / Bazel didn't even exist, when Autotools was considered the best system to configure your build (ah!), and GNU Make 3.81 was considered new and bleeding edge, and didn't necessarily exist for all platforms. I'm not even sure pkg-config was available on all Linux distros until quite a long time. As I said ... very different times.

Despite that, it was also designed to make FreeType buildable on a maximum amount of systems, and I attribute part of its success to that specific feature, especially in the embedded world. While we probably no longer care about developers using DOS and OS/2 systems to build the library, I would really appreciate if any replacement could continue in this direction.

I think it would also be acceptable if the build system used to develop FreeType itself, might be different than the one used by other developers that simply want to use it in their own projects. For example something that can build and run tests easily with sanitizers, fuzzing, remote bots and other goodies, or can integrate well with a continuous integration system. While at the same time, being able to generate simple Makefiles / CMakefiles / BUILD / BUILD.gn / whatever corresponding to a specific configuration of the library (which is what 95% of developers using the library need).

I have experience with CMake (I find it a vast improvement over auto-tools for package / feature detection, but a hot mess for about anything else), GN/Ninja (very powerful, but essentially requires too much dependencies to get the most out of it) and Bazel (can be hard to get into, very powerful, but requirements are a bit crazy at the moment). I'm curious about Meson.

I don't have something specific to propose, but that's my current point of view. I may be wrong or misguided, so please share your feedback in this thread.

Let the flame^W war^W games begin :-)

- David



--
behdad
http://behdad.org/

reply via email to

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