Date: Thu, 23 Dec 2021 15:22:17 -0500
From: Christopher Wellons <wellons@nullprogram.com>
To: Harris Snyder <harris.snyder@gmail.com>
Cc: ~skeeto/public-inbox@lists.sr.ht
Subject: Re: Meson/Ninja?
Message-ID: <20211223202217.qzsuyjoidpcdl7bk@nullprogram.com>
References: <CAKF5_T=0JTOU=AGVGF-u6J5RKRtRQ5YP0X85Rr4g=Q=V2GFd3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKF5_T=0JTOU=AGVGF-u6J5RKRtRQ5YP0X85Rr4g=Q=V2GFd3Q@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)

Interesting question, Harris. Since Make has served me well enough all 
these years, I haven't had much reason to look at Meson or Ninja. I don't 
like dependencies, even build dependencies, that don't bring something 
substantial to the table. Make is a standard development tool with 
multiple, independent implementations, and so, in practice, it's not 
really a dependency. Like, say, a text editor, it's safe to simply assume 
it's present alongside a compiler, even on Windows. I include Make in 
w64devkit after all, so there's really no excuse not to have it on hand 
when building my software.

I was aware of Ninja due to it being an output option for CMake, though 
I've never used that feature. It's written in C++, which is reasonable 
enough for me to consider it. Though Ninja is low level in the same way 
Make is low level, so it's not bringing anything new to the table. It 
claims to be faster, though that won't apply to the way I build software, 
where Make already consumes less than 0.01% of the total build time (full 
build), and only a couple of milliseconds when there's nothing to do. The 
website says you're not really supposed to write Ninja build files by 
hand, and it's intended to be generated by yet another build dependency 
(CMake, Meson, etc.). So I see no benefits versus Make, just the cost of 
an extra dependency and an unconventional build interface.

When I've run into projects using Meson, my reaction has always been to 
roll my eyes and bypass Meson, manually invoking the compiler on the 
source files. These projects have always been simple enough that they 
don't even need much of a build system, let alone an esoteric one.

Looking more closely at Meson now, I see its written in Python. This is an 
inappropriate implementation language for a build system, and more than 
enough reason enough for me to never touch it. A build system ought to be 
written in a systems language. If I depend on Meson, then I also 
transitively depend on a full Python interpreter and package system (to 
install Meson) since the Python community has yet to solve distribution / 
delivery. Fortunately Meson doesn't have further Python dependencies of 
its own, so at least it's not nearly as bad as it could be.

Trying it out some existing Meson builds listed on their site, I see it 
makes a common mistake with CMake: The output build scripts contains 
absolute paths to the project itself. A consequence is that I can't mix 
tools with different views of the file system. For example, tools running 
in Cygwin or Msys2 see different paths than native Windows tools, so they 
may be confused when invoked by Meson or CMake builds from the other 
system. This was at one point a deal-breaker for me with CMake. Though it 
seems Meson uses relative paths more than CMake, so maybe in practice it's 
not an issue.

The only build system I've ever liked more than plain old Makefiles is "go 
build". Unfortunately it's too late for C and C++ to have something like 
that — the ecosystem has been fragmented into incompatible ways of doing 
things for far too long.