[Strategic considerations for meson] Making meson great again - or, more accurately, making meson the winner in the epic duel between GNU configure, meson and cmake

[rubyFeedback]

So ... this is more an invitation to discussion. I deliberately chose a title that is "catchy". More people chiming in may make this interesting rather than boring for discussion.

However had, I also understand that issue trackers need to be kept clean. So, I would like to ask for this issue to stay open for, say, a full month from now on. After that I recommend that anyone closes it, unless you may consider it more fruitful for further discussion. It is, however had, mostly meant for a discussion about "meson's future" (that's another catchy expression).

While the issue is aimed mostly for Jussi, I am of course referring to ALL meson devs as well as meson users and other stakeholders.

Anyway, to the issue soon - but let me first start (or rather proceed now) with a BACKGROUND rationale. That way it may make more sense to folks who are confused about the title.

---

I have been using Linux since, say ... 2004 or so.

Back then I started to experiment ... first, red hat, then debian, later knoppix, kanotix.

I also found rubyX and heretix - which both died. They had as an idea to put ruby first to manage everything. Quite neat idea.

Anyway. Back then I also found GoboLinux. The hierarchy made more sense to me, so I started to experiment. The "one program per directory" model is still superior to the default FSH on linux.

NixOS kind of pursues that (if we look past the fact that hashed directory names such as 3789579823-523823593826623-236632263632 are mega-ugly, but a reproducible system is a GOOD idea).

During that time I started to compile stuff. I love compiling. It's like LEGO building in a way.

So, with that background in mind, I also created a project long time ago - primarily written in ruby. That project is here: https://rubygems.org/gems/rbt and the lengthy documentation (which I really have to rewrite and clean up ... I am lazy) is here: https://www.rubydoc.info/gems/rbt/

Alright. That project is fairly big, and totally useless to about 99.9% of people who may decide to visit these boring pages. :D

However had, one commandline flag may be semi-interesting, and this is how we are getting closer to the main issue here for this issue request.

Via:

rbt --compile-statistics

I keep track of the projects that I have registered.

Right now I am keeping track of 3763 different programs. Not bad. \o/

It's a bit similar to homebrew, but homebrew is bigger and keeps track of more programs (I think).

Anyway, here is the partial output from the compile statistics above.

There are a total of 3764 registered programs in the RBT project.

597 programs depend on cmake.  15.9% ( 597 / 3764)
305 programs depend on ruby.    8.1% ( 305 / 3764)
191 programs depend on python.  5.1% ( 191 / 3764)
171 programs depend on meson.   4.5% ( 171 / 3764)
 62 programs depend on perl.    1.6% (  62 / 3764)
 14 programs depend on scons.   0.4% (  14 / 3764)
  3 programs depend on waf.     0.1% (   3 / 3764)
---
1343 programs make use of any of the above ^^^ compile-time strategies.

2421 programs are assumed to be compiled through make (and possibly
     GNU autoconfigure). Note that meson depends on python,
     so strictly speaking, the meson-dependencies overlap
     with the python-dependencies.

(Don't worry about the 3763 versus 3764 difference; I probably added a new program but forgot to add some meta-data.)

So what can we see here? Well. GNU configure still dominates by a LOT. cmake is catching up a bit, at 597 programs. Meson at 171 is third.

Here I have to add that the above is NOT representative!

It is heavily biased. For instance, I keep track of all KDE programs, so of course they depend on cmake. Thus the above is NOT representative at all. It's also not 100% accurate. Anyway, in a few years I think I will have better data. The above is biased to my own use cases. I think debian may yield better statistics, but I have no idea how to query that.

Alright so now to the issue here:

I have used plain Makefiles, GNU configure a lot, cmake as well as meson/ninja. I even read Jussi's .pdf about meson, but only like the first 50 pages or so (I have an attention problem...)

From all the build systems, meson/ninja is by far my favourite. It is SUPER fast, and it works fairly well, and it isn't as user unfriendly as cmake is (those who used GNU configure may relate to that, no idea why cmake became that popular - probably because GNU configure is a pain for developers).

I'd like for meson to really push the lead here and dominate over the other build systems. So this should be a strategic consideration to make meson the dominating build system. I guess most may agree that this could be a good idea. One build system to rule them all. Fast, reliable, documented, useful, user friendly. You name it.

In part the above is also a request to not neglect windows. I hate GNU configure on windows. Using msys2 is also not so great either - I'd love for both cmake and meson to make it really simple to work on windows too and compile stuff there.

Many of the oldschool projects, say ruby or python, use GNU configure. I'd love for them to use meson instead. No idea how to do that - guess once meson hits a critical threshold more and more devs may switch to it.

So, how to make people switch to meson? I have no idea myself. But I think it should be tried. It should be a strategy to get people to move, and probably add as much useful documentation as is possible to effect that goal. Guides how to write something, say, a small C++ library, how to quickly generate the code to get it to compile - so that meson can be used rather than a Makefile, for instance. Perhaps even on windows as-is.

If anyone has more ideas here to push meson, perhaps you could add to this - a bit of a brainstorming idea. I'll leave it at that, but I probably forgot tons of things - achievable steps for that strategy or goal. I know most GNOME software uses meson, but outside of that I am not so sure. And, perhaps even try to get the KDE devs to consider switching to meson. I know, I know, this is currently probably not likely to happen, but who knows - in 2 years perhaps they may consider meson if it brings a substantial improvement to them compared to cmake. (I think it has to be substantial because they abandoned GNU configure because they hated the macro hell situation of maintaining that spaghetti code, so I guess they want to only move away from cmake IF meson is better.)

[xclaesse]

Is there an actual issue in all that ocean of text?

[Akaricchi]

Is there an actual issue in all that ocean of text?

I've read it so you don't have to; the tl;dr is I want all software to use meson, let's brainstorm our world domination plan together.

[eli-schwartz]

I'd like for meson to really push the lead here and dominate over the other build systems. So this should be a strategic consideration to make meson the dominating build system. I guess most may agree that this could be a good idea. One build system to rule them all. Fast, reliable, documented, useful, user friendly. You name it.

I agree, and further propose that our world domination plan should be:

To write excellent software that everyone loves to use.

It should be a strategy to get people to move, and probably add as much useful documentation as is possible to effect that goal. Guides how to write something, say, a small C++ library, how to quickly generate the code to get it to compile [...]

Documentation is always wonderful to have, although sadly it tends to get less of a focus from people who want to contribute. I'm eminently guilty of that myself as well.