psychonic
commented
9 months ago Thanks for doing this.
I think that those insights are helpful as we evaluate more common systems, while also keeping in mind our unique needs. MM:S/SM are special ducks (pun only partially intended), and it's nice to know what our options are as we go through other large changes driven by Source 2 and other game changes.
c0nstexpr
dvander
AMBuild predates most hot new build systems. It's almost as old as CMake. It has evolved to solve a lot of really idiosyncratic problems and is very flexible. However, it is both a frontend and a backend. Most modern build systems are frontends only, which means they are very good at integrating with IDEs. AMBuild prioritizes its own backend, so it is very bad at IDE integration. This creates a lot of friction for newcomers.
I did some preliminary investigation into switching to meson. I did my homework, and am leaving the code here in case anyone wants to continue further: https://github.com/alliedmodders/metamod-source/compare/master...meson
My observations are below, from "most problematic" to "me just being nitpicky". Despite this I actually really like meson. It's simple, and fast, and very easy to write. I had fun with it. I might add support to SourcePawn for it. But I don't see that any major, complex projects use it, and them fixing items (1) and (2) would go a long, long way into making that possible.
Is this a showstopper? For me, integrating with legacy MM/SM, it is. It would require a major rework of buildbot to merge packages together. It's important for usability that people can just download a single package and don't have to worry which game they have. This is not a unique problem - many projects, especially mobile ones, need multilib and fat package support, and other build systems can do this without needing a wrapper script.
For someone writing a new build system from scratch for Source 2, I think meson would be fine, as there are only 64-bit binaries going forward.
meson does not have custom functions or macros. They do not budge on this, which strikes me as very unfortunate. I think for Metamod we could squeak by by packaging lots of information up-front into dictionaries, which is what I did in the sample code. I have no sense whether this would work for SourceMod. It probably would, but this limitation worries me. "Cannot write a loop without a backing array" worries me. "Cannot run a program as part of the configure step and parse its output" worries me. It's an extremely serious limitation.
meson has no way to read environment variables. They do not budge on this. Maybe they think ENV isn't hermetic? Which strikes me as a misunderstanding if true, but we'd need to rework the build server since it relies on ENV heavily.
meson has no encapsulation or scoping. Every variable is readable throughout all meson.build files. "That makes sense, if variables are immutable" you say - but no, data is immutable, and variables are not. So, modifying dictionaries is pretty verbose. But hey you can modify them anywhere by accident! In the sample code I tried to rigorously use unique variable names because I kept accidentally making subtle bugs.
Dictionaries don't appear to have any default getter. This makes dictionary code really verbose. I couldn't see anything in the docs saying otherwise.
Checking for compiler flag support is pretty verbose, and expensive since it has to invoke the compiler. AMBuild is faster to configure which is pretty funny given how thrown together it is. There is no way to check compiler versions with meson.
Adding custom flags is very verbose. It's probably best done in a temporary array, but I didn't think of that until now.
meson does not prioritize clang or let build rules force it. We do not support GCC, so users will always have to "CC=clang CXX=clang++".
The meson build language tries to look like Python, but subtly changes the syntax in ways that trips up a frequent Python user. Eg, statement blocks don't end in colons. Keyword arguments use ":" instead of "=". My guess is the authors didn't want to think about indentation. But why have "endforeach" and "endif" rather than a single block terminator keyword?