This Weekend in Meson++ (January 31st)

 It's been a busy week(end) for Meson++ this last week, with lots of exciting features landing. We're rushing toward the possibility of self-hosting, which is a very, very exciting milestone for me.

Preliminary custom_target support

This is one of the biggest features still missing from meson++, and is one of the biggest reasons to use a build system like meson instead of plain makefiles. The support is rather basic, it only includes support for outputs, with inputs not yet working, as well as some of the templatizing parameters (such as @BASENAME@ and @PLAINNAME@ not yet implemented). Those should be smaller, more incremental improvements though, and meson++ itself needs this for flex and bison

Splitting the Ninja Backend

One of the design issues in meson, is that ninja was the first backend written, and thus a lot of assumptions are made about backends in general. We have to a fair amount of rematerialization in the xcode and vscode backends, because the generic backend is very file centric. I.e., it assumes that targets in the backend are rules based on input files and output files. xcode and vscode don't work exactly that way, even though make and ninja do.

In order to not have that same issue in meson++, I designed the MIR (Meson IR) as a relatively generic IR. Target dependencies remain in place in the IR, and though we do lowering, we don't get to such a lower file-in/file-out model.

Previously this meant that the ninja backend lowering call would walk the MIR it was provided, generate rules, and then emit those rules. The Rule type was really a Target (bad naming), and was a generically useful low IR for file-in/file-out backends, such as ninja and in the future make. I've split that out into a new code unit, FIR (File IR), which can be shared, and protects against layering violations.

Why Make?

You're probably about to ask why I'm concerned about Make, especially since Meson doesn't support it, and is unlikely to ever implement one. The answer has to do with my primary motivation in Meson++, which is bootstrapping and early bring up. As Meson becomes more popular in low level projects, it runs into more cases of needing to support OSes that may not have ninja in their lowest bootstrap chain, but likely do have Make (I'm looking at you, BSD family). A Make backend would be really useful for some of these cases.

Equality Operations

Another major piece to put into place are equality operators, and the first batch have landed. This currently only allows numbers, booleans, and strings to be compared, with arrays, dictionaries, and more complex types not yet supported. I've also implemented the newest meson behavior, comparing non-like types is a an error, so something like `1 == true` is a fatal error.

An interesting, and annoying thing I ran into is variant comparison in C++. Variants have equality operators, which would do what I want, except that the variants are holding either shared_ptr or unique_ptr instances. the equality operators of those types is not what I want, so I get to write the long chain of std::holds_alternative and std::get to compare.

All the Small Things

  • A fix for operator precedence in chained methods, allowing things like `meson.get_compiler('c').get_id()` to work was added
  • A fix for assert lowering
  • depfile generation and useage support was added


Comments

Popular posts from this blog

This Weekend in Meson++ (February 6th)

Introducing Meson++

Rust in Meson — 0.57 Edition