freetype-devel
[Top][All Lists]
Advanced

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

Re: Build system considerations


From: David Turner
Subject: Re: Build system considerations
Date: Fri, 1 May 2020 00:52:16 +0200



Le jeu. 30 avr. 2020 à 23:33, Albert Astals Cid <address@hidden> a écrit :
El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va escriure:
> 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.

I am afraid that is your very biased life bubble.

I'm not sure you realize that what you wrote sounds insensitive and is bordering ad-hominen.
You could have said that you disagree and that this doesn't match your experience for example.
Instead you tone devalues the point you're trying to make.
 
CMake is the industry standard.

I know comparisons are not easy, but let's search for "project" (a keyword my little knowledge of meson says that is present in all meson using projects) in meson files in github
https://github.com/search?l=Meson&q=project&type=Code
6500 instances

Now let's search for CMAKE_CXX_STANDARD a keyword in CMake used for C++ projects (and not even mandatory to use)
https://github.com/search?l=CMake&q=CMAKE_CXX_STANDARD&type=Code
246000 instances

And that's not including the C based projects or similar.

I know you don't have to choose build systems based on popularity, but saying that meson is sidestepping cmake is far from the truth.

 
I think Behdad was talking about the Gnome world here, not the rest of the industry / open source community.
In all cases, I'm not a big fan of blindly following industry standards just because they exist (*cough* _javascript_).
 
Just to clarify again for the context of this thread:

A) One of the major features of FreeType is that is can be easily built on many many systems (included embedded ones with weird toolchains), and it's something I'd like to keep for the core library.
  In other words, I really want to keep the ability to compile an official release of FreeType with "./configure && make". That doesn't mean we have to use auto-tools or the current Make-based system though.
  We may also consider providing CMake scripts to help use of FreeType releases into CMake-based projects.

B) For people developing FreeType (instead of using it in their project), it would be really useful to have a better build system to use. E.g. one that allows building _and_ running tests easily, at a minimum.
    I'd like to see easy support for cross-compilation, or even remote cross-compilation (e.g. being able to automate a remote build on a Windows or OS X machine through SSH is invaluable when doing cross-platform development, as I have done that in the past), but these are minor compared to the ability to run tests as soon as possible.
    This second build system might be completely different from make/CMake, and I don't care at all as long as we can support A) properly. Keep in mind that FreeType has very few developers (which is perfectly ok), so choosing a solution that brings joy is more important than something that could support a team of 50 people working on it, or is industry standard.

I guess the best thing will be to experiment with several build systems to see what they can offer. I'll try to setup something this week-end, but feel free to contribute something so we can all check that.


Cheers,
  Albert

>
> 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
> >
> >
>
>





reply via email to

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