This Weekend in Meson++ (January 23rd)

 Assert() and unary operations

We have assertions, which are super useful for unit tests. There's still a bit of work as we don't print location data (like messages), but it's enough to be useful for testing, which is frankly what assert() is for.

Interestingly, with assert() we really need at least the `not` keyword. This wasn't too hard to implement, but turned up some bugs. Basically at the MIR level, we treat everything as control flow or an object. Function calls are objects too. In this case the not keyword is lowered to a not() function, which takes a boolean and returns a boolean. I did uncover a parser bug in the process, which was thankfully easy to fix.

I wrote the following code:
assert(not x.found(), 'message')
The way this is supposed to be parsed is as
assert(not(x.found()), 'message')
but it was getting parsed as:
assert(not(x).found(), 'message')
Which is obviously wrong, and not what we want (thankfully booleans don't have a found method). Thankfully changing operator precedent in Bison/Yacc is super easy, move the lower precedent up in the file.

find_program()

Finding programs is pretty important for nontrivial builds, meson++ uses this to find flex and bison, for example. One of my goals in using an optimizing/lowering compiler model instead of a just-in-time interpreter, is that it should make doing work in parallel very simple. For example, finding programs. In meson (and muon) programs are found as they are encountered in the AST, and they hold up further parsing until they are available. Meson++ does not have this restriction, and instead we do the following
  1. Lower/optimize as much as possible
  2. using threads, search for all programs
  3. replace any calls to `find_program()` with the Program objects
  4. lower again (hopefully completely)
This means that we not only get the faster performance of C++ vs Python, but we can also find multiple programs at once. For a truly large build like mesa, this can speed things up significantly. Eventually I'd like to also do dependency() and compiler methods in the same threaded loop. This could result in some wasted effort (such as looking up a find_library() after a dependency check()), but I think the parallelism will be worth it.

Having find_program also means we're on our way to being ready to implement custom_target, which is a big blocker for getting toward self hosting, but not as big as something like test() which will be a massive undertaking to implement. 

Comments

Post a Comment

Popular posts from this blog

This Weekend in Meson++ (February 6th)

 Meson++ is 1 year old! It's strange to think that February 9th, 2021, was the first commit to meson++, and a year later, we have a working flex+bison C++ frontend, an optimizing mid level IR, a file based backend IR, and the ability to generate simple ninja programs! It's a strange and proud feeling.  Anyway, I haven't implemented any sweepingly huge features this week, but we have landed support for `declare_dependency`, an important first step toward real dependencies (like those found by pkg-config). I also implemented a simple optimization for finding unreachable code. In this case, we look for the `error` function, and mark any instructions after that as dead, as well as removing any next block. Currently, there are no other non-returning functions implemented, but eventually `subdir_done()` will also need to be handled (though `subdir_done()` may present other problems for me). I also started implementing some neat argument pack based variant argument extractors. The
Read more

Introducing Meson++

I've been semi-quietly working on a new project for the last few months on and off, and today I've gotten far enough that I want to talk about it more widely: Meson++ . Meson++ is now capable of compiling very simply projects, if they meet the following criteria:  they use only C++ they don't have any external dependencies they only build executables they don't do any code generation you're okay using ninja you're using clang or gcc This may seem like a lot of restrictions, and it is, but there's a lot of code that has gone into getting to this point. I'd like to thank stackoverflow for answering a lot of questions. Motivation My primary motivation is to solve bootstrapping issues, imagine if python wanted to use Meson, currently that would create a bootstrap loop, where you need an old version of python to run an old version of Meson, etc. Or, imagine you want to build something like your compiler with Meson, now you need to build python bef
Read more

Rust in Meson — 0.57 Edition

Rust in Meson 0.57 Most people by now have heard of the meson build system I hope (at least anyone who would bother to read this blog post), and Rust is the cool new language everyone wants to use because it guards against specific kinds of memory bugs and has some neat features. The question of course is how to add rust to your existing project using C, C++ or another language. The answer of course, should be build your project with meson. I’m not going to go into whether using Rust is a good idea, whether it’s going to solve all of your problems, eat your puppy, or any of that. Rust, like everything else we do in programming comes with a set of trade-offs. I’ll say though, for the record, that I like Rust as a programming language form the relatively small amount of it I’ve done. So here’s a run down of what’s coming in the meson 0.57.0 release for Rust. Meson level handling for rust editions. Rust editions, for the uninitiated, are roughly equivalent to standards in C and C++.
Read more