Porting Mesa/Libdrm's Build System To Meson Brings Up Controversy

[doom_Oo7]

Ninja in itself is not significantly faster than Make (and Meson definitely isn't).

I disagree. While the initial build is roughly similar in speed between ninja and make, subsequent builds (when only one file out of hundreds changes) are significantly faster with Ninja than with Make. Just did a test with my software and a "make all" after a single change takes tens of seconds more with make than with ninja.

[Elyotna]

Everybody should just switch to GN/Ninja like chromium does.

[starshipeleven]

Someone could go rewrite it (or provide an alternative implementation) in Rustor C or whatever

rewrite it in Rust

rewrite in Rust

in Rust

Rust


I approve this.

[ldo17]

... whereas in Make you need to turn that feature on explicitly using -j.

Please, always say “make -jn”, never “make -j”. Do you know what happens when you run an actual “make -j”? I have tried it myself, just for (masochistic) fun...

[ldo17]

The build scripts are not Turing complete ... This is considered an advantage.

I’m not sure why. Sooner or later you will need to run custom command sequences at build time, and then what do you do?

[unixfan2001]

Please, always say “make -jn”, never “make -j”. Do you know what happens when you run an actual “make -j”? I have tried it myself, just for (masochistic) fun...

The last time I tried that I went on a drunken frenzy, poured gasoline over my computer, torched it and woke up naked, in the woods.

[unixfan2001]

I really wish there were decent, general purpose build systems not written in Python.
JS/TS (via node) or Golang would, IMHO, be very good languages for that.

[unixfan2001]

I’m not sure why. Sooner or later you will need to run custom command sequences at build time, and then what do you do?

Cue "Mozilla mach", where I'm running into that exact problem currently.
As nice as it is knowing that the build system can't easily break or be exploited by changing a configuration file, it's also a massive pain in the arse when one actually has to add new features.

[ldo17]

I really wish there were decent, general purpose build systems ...

While that may be less unrealistic than a “decent, general purpose IDE”, I don’t think it’s possible either.

[emblemparade]

While the initial build is roughly similar in speed between ninja and make, subsequent builds (when only one file out of hundreds changes) are significantly faster with Ninja than with Make.

Ninja would be faster in such cases only if you set up incremental compilation (deps) with gcc etc. Of course Make supports it, too, and indeed the deps format used by Ninja is actually copied from Make (because all compilers support Make). But there's nothing in Make that would make it slower here.

But I do hear you more generally: the whole autotools route is very complicated. Writing a robust and efficient Makefile by hand that supports incremental compilation is hard. I see so many Makefiles out there that are incredibly inefficient. People just accept that it works and are good with that. We want to write code; who wants to waste time on the build system? So, the advantage of using these more modern frontends is that an optimized Ninja file (or Makefile) is produced for you and you don't have to worry about these details. A good comparison would be to use CMake with either Ninja or Make -- you will find the end result equally fast. I suggest you try it if you want to be convinced. (Again, I still prefer Ninja myself, but the reason is its minimalism, not its speed.)

Sorry for confusing people with my `make -j` comment. Of course you want to add a number after the j!