CppCast - Mesonbuild

Episode Date: December 17, 2015

Rob and Jason are joined by Jussi Pakkanen to discuss the Mesonbuild multiplatform build system for C++. Jussi Pakkanen got his doctoral degree in computer science from the Helsinki University of Technology in 2006. Since then he has worked on various problem areas ranging from mail sorting to the software stacks of Ubuntu desktop and phone. Most recently he was the SDK lead developer at Jolla. Currently he is open for new development challenges. During his spare time he has been known to be a photographer, movie director, magician, gastronomist, computer game designer and watercolour painter. News Under the Hood: Leap Motion Hackathon's AR Workspace STL Fixes in VS 2015 Update 1 Meeting C++ Lightning talks are now on youtube Jussi Pakkanen Jussi Pakkanen's blog @jpakkane Links Mesonbuild Mesonbuild on GitHub Making build systems not suck

This episode of CppCast is sponsored by Undo Software. Debugging C++ is hard, which is why Undo Software's technology has proven to reduce debugging time by up to two-thirds. Memory corruptions, resource leaks, race conditions, and logic errors can now be fixed quickly and easily. So visit undo-software.com to find out how its next-generation debugging technology can help you find and fix your bugs in minutes, not weeks. Episode 38 of CppCast with guest Yussi Pakkanen, recorded December 17, 2015. In this episode, we discuss a futuristic AR workspace

and the C++ code behind it. Then we'll talk to Yussi Pakkanen about MezenBuild. Yussi will tell us about some of the key features and advantages of Mein Build. Welcome to episode 38 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Good, Rob. How about you?

Doing good. A little off-topic, but today is actually, is it the day of or the day before the new Star Wars movie is coming out? Are you planning on seeing that when it comes out? I do not yet have plans to see it, although it seems it's opening here today where i currently am which i'm a little confused by i thought i was supposed to be opening the 18th but it might just be like midnight showings today i'm not sure about that no 7 p.m starting in the atlanta area oh wow i don't know yeah i bought tickets like a month ago for my son and i to see it on Saturday. So the next two days are really going to be tough for me just knowing that I could see it. But I'm waiting because I bought the tickets already.

But I'm really looking forward to it. Anyway, though, at the top of every episode, I like to read a piece of feedback. This week, we got some tweets in after Eric Niebler's episode on ranges. Christoph sent in this tweet to us and Eric saying that there are some compiler flags that you could pass in to the Clang Microsoft Visual Studio integration to try to get ranges to compile.

And it looks like it does work, and Eric replied to that. And it does work only if he tries to use a view for each, he still gets some errors. But it sounds like they're making progress, that they should be able to get ranges to compile in Visual Studio, which is pretty cool. Cool. And that seemed like it was a pretty popular episode also. Yeah, I think we got a lot of great feedback from that episode. And it was great talking to Eric. Very interesting stuff. Definitely.

One other thing worth mentioning, he mentioned it to us and he announced it to everyone else right after the episode published that he's moving on to work at Facebook, which is pretty cool. Yeah, pretty crazy. Amazing how many top talent Facebook can attract. Yeah. Yeah, definitely. Well, we always love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And always don't forget to leave us review on iTunes because those really help us find new

listeners. So joining us today is Yussi Pakkanen. Yussi got his doctoral degree in computer science from the Helsinki University of Technology in 2006. Since then, he's worked on various problem areas ranging from mail sorting to the software stacks of Ubuntu desktop and phone. Most recently, he was the SDK lead developer at Yawa. Currently, he's open for new development challenges. During his spare time, he has been known to be a photographer, movie director, magician, gastronomist, computer game designer, and watercolor painter. Yussi, welcome to the show.

Glad to be here. Thanks for joining us. You know, I don't know which one of these to bring up. Magician, movie director, gastronomist. Let's go with gastronomist, yeah. What gastronomy do you participate in um well so um i'm i'd like to go every now and then to these slightly fancier restaurants or the ones with the michelin stars oh okay which is just fun i think i've only been in the vicinity of a michelin star restaurant once and it was like $15 for a

grapefruit for breakfast and I decided that was too expensive for me yeah yeah it's it's a fair bit expensive but um you have to spend your money somehow so yes one way to do it it's a certainly a hobby okay well uh we've got a couple news articles to discuss before we start talking to you about Nissan build, but feel free to chime in. This first one is pretty interesting. It's on the Leap Motion blog, and it's talking about this hackathon project that they did, which apparently got some attention from like Wired Magazine. It was all over Reddit and it's this augmented

reality workspace they created where I think you're wearing an Oculus rift and leap motion is involved to capture hand gestures. And you're able to move around the windows of the, of the desktop, like in a virtual space and do all these other crazy things. I just thought it was really interesting to watch. And then they posted a lot of their C++ code in this blog entry showing how they did it. And apparently

they set up this whole thing in just a couple days. It was a hackathon project, which is pretty impressive. Jason, what were your thoughts on this? Well, just from a watching lots of science fiction movies kind of Well, just from a, you know, watching lots of science fiction movies kind of perspective, I'm like, you know, we've been waiting for this kind of thing

for, I don't even know, 30 years, and it looks like it might actually become a reality soon, where you might be able to manipulate, you know, a virtual environment around you, and it'll be useful, not just something that's a cool trick yeah between hololens and what you can do with the oculus rift and some of these other technologies it definitely seems like we're on the verge of this becoming you know more of a thing that you would encounter in the real world yeah you see do you have a chance to look at this as well? Yes, I've looked into this, and I used to work on the touch stack of Ubuntu,

like gesture recognition and stuff. It's interesting stuff. For actual use, there are a few problems. One of these is called the minority report problem, which is that if you wave your hands in the air, it looks pretty cool, but if you do that for an extended period of time, then you get really tired. And the reason people don't move their hands much when they're on the keyboard is very good, because the muscles don't get used as much.

And it's really nice. And the other thing is the gesture recognition. So this is one of the things that it's really hard to detect them reliably. And if you do the wrong thing, then people get frustrated very easily because undoing the thing, the wrong gesture, it always takes a lot of effort.

So these are the problems that it's going to face, but hopefully they'll get it solved because it looks pretty cool. I have heard about the minority report problem. Apparently, when Tom Cruise was filming that movie, he actually, his arms got physically fatigued while doing all those scenes while moving around the virtual screen.

So it is definitely a real-world problem. I think what this is trying to do, though, is you're not doing everything with your hands. I think you would still be typing with a normal keyboard. It's just instead of moving your mouse and dragging over some window, you could use these hand gestures, which is pretty cool. Anyway, the next article is from Visual C++ blog from STL, just going over some of the STL fixes that he put into 2015 update one. And really the most significant thing here

is that they put in STL fixes in the update. Apparently that's the first time they've done that since 2010's update one. And he's saying that it's not because there were severe bugs, but just that they're trying to deliver fixes faster to the users. And he also mentions how there's the partial SFNA support in here.

Jason, was there anything else you wanted to bring up with this? I do really appreciate that they are pushing out fixes better, faster. And you just, you know, just on a meta level you have to appreciate when STL writes about the STL. Of course. But anyhow, I also find it interesting. There's several little details in here about interoperability with clang. And, uh, that's, that's good. And that's going to be

something that we're going to need more. Like we referenced back, um, to Eric Niebler's discussion about supporting, you know supporting better C++ standards across all the compilers. Yeah, and hopefully they'll keep working on this. Maybe in update two, they'll release some more STL fixes and we'll be able to fully build ranges. That'll be nice. Okay, and the last article is from Meeting C++,

and they're just announcing that they released all the lightning talks onto YouTube. And Yusi actually pointed out right before we started recording that they also posted the keynotes, which I'm going to have to go watch. Who was the keynote this year? Was that Chandler Carruth? Yeah, so they only had the one keynote at that time of recording. Okay, so they had additional keynotes, they just only posted the one keynote at that time of recording. Okay. So they had additional keynotes that just only posted the Chandler-Kruth one so far? I think that's the case, but I'm not entirely sure. Okay.

Well, those are all, or at least the lightning talks and the keynote are on now, and I'm sure they're going to post more content very soon. Very cool. So, Yussi, let's start talking about Misan Build. First off, am I pronouncing that correctly? This is the thing that I'm not entirely sure because the word is the elementary particle physics. It's one of the building blocks of the universe. But I'm not entirely sure what's the correct way to pronounce it if you're a native English speaker, but I just call it

Misan. Man. Okay. Okay. So can you give us an overview of Mezzan Build? Okay. So I'd like to start off with a quote. So this was a quote by Robert Ramey. You had him on the guest, I think. So he had a presentation a year ago at CPPCon, and he was talking about Boost and all that sort of stuff. And then he had a slight interjection where he said that,

let's talk about build tools at this point. All build tools suck, and that's just the way it is. And then he continued on with other stuff. And it's like, Mezen is kind of like an attempt to like, well, this really shouldn't be the case, because a build tool is not that complicated. We should be able to make one that is just as nice as like the C++ compilers that we use or the IDEs that we use. And that's kind of like the goal of the project.

So how does the build system work? Is it more like CMake where it generates native project files for each platform or is it its own standalone build system work? Is it more like CMake where it generates native project files for each platform or is it its own standalone build system? So it's pretty much like CMake. So one way of looking at it is kind of like an alternative front end to the same kind of functionality that CMake has. So because CMake has a really nice back end, so the way that it generates these projects for Make and all of that, it's actually really nice.

Okay. And during the development, whenever I was like, well, what should I do in this case? I just wrote a CMake script that did what I wanted it to do and then saw what it did and the actual compiler invocation that it did, and then it just sold those. But then it's just the front-end is completely different because people have strong opinions

about the CMake definition language. So the goal was to make one front-end language that's better. So what is the front-end language like? Is it an existing programming language we all know?

So this is a custom DSL, so it's a language that's only used to specify this. The thing that makes this one special is that it's not Turing-complete. So there are no functions and there's

no recursion and all that sort of stuff. But instead, it's just a linear progression. All the state is immutable. So once you create something, it will never change. And this makes it a lot easier to reason about what's going on in your build definition. But on the other hand, there are things like QBS, which are declarative. It's kind of like SQL, where you just have a list of

facts and then the system from those computes something else. And MetaNissan is imperative so it goes line by line and you can put in print statements to debug your stuff and all that sort of stuff. So the idea is that it's as simple as possible but without cutting down on the power that you need because you need to do various weird things like compile source codes into programs which you use to compile more source code and all that sort of stuff.

Yes, I've definitely had to deal with situations like that where you have to build the code generator to build the rest of the project. So that is something that Mason supports? Yeah, so that's natively supported, and as a further twist, so if you have cross-compilation, then you have a problem because first you compile the binaries,

and then if you try to run them, you can't actually run them because they're cross-compiled, so they would only run on the target. So what Meson is, it has a concept when you do cross-compilation of native targets and cross-compiled targets. So if you have a tool that you're going to use during the build, you can just say, I want this target built with the host compiler, or that build compiler, and if you have something like on Linux where you have Wine and you can use run Windows programs,

then you can specify that these tools that you build should be run with Wine, and then it does it transparently. And it also does it for your unit tests. So you can develop on whatever platform you have, let's say Linux, and if you want to cross-compile to Windows,

you can do that, but you can also run your entire test suite. Wow. I'm already thinking of situations where I might be able to use something like that. Like when building a programming language interpreter and then running tests against it or something like that. Yeah.

Very cool. So what platforms does MISAM build support? So the biggest one is Linux, because that's what I use for day-to-day development. And then there's OS X. And then it also supports Windows, with GCC and Visual Studio. And I've also gotten some reports that claim for Windows is working.

And then there are people who are using it for something like bare metal coding. So without any operating systems for the cross-compilation. And I've gotten reports of people who've been using it to compile stuff for Android. And I've been using it for at least the test suite runs for when you cross-compile to iPhone.

But I haven't actually tried it because I don't have the hardware myself. All right. That's pretty cool. So do you create Makefiles on Linux and macOS, I assume? So the thing is that Mesin doesn't have a make backend. Oh, okay. And the thing is that as long as I'm the maintainer, it's not going to have a make backend. Okay. And the reason for this

is that make is terribly, terribly slow. And it is not an implementation detail, but there are things in the make language the way it's defined. It cannot be fast. And instead, what we use is something called Ninja, which you can also use with CMake and a bunch of other stuff,

which is kind of like Make, but it's very, very streamlined, really nice to use, and it's really, really fast. I've heard some great things about Ninja's incremental builds on very large projects. So if you compile Clang, this was a few years ago when I tried this, and with CMake, you can choose between the Make backend and the Ninja backend. And if you compile it, and then you run Make again without any changes at all, it takes about 30 seconds just to parse out the files and do the stats and see that everything is all right.

And then you do the same with Ninja, and it's less than one second. Wow. So then on Windows, are you also creating Ninja files, or are you using Visual Studio? So Ninja is what's supported on all platforms. Oh, I see. Okay. And then on Windows, we also generate Visual Studio files, but it's not as polished as the Ninja backend. And then on OS X, we also generate Xcode projects,

but that might even be broken at the moment. The file format of Xcode is not the most pleasant to work with. Let's put it this way. Is it at least stable, or is it something a constantly chasing target you have, too? It's quite stable, but it's basically a memory dump

as opposed to a real thing. Speaking of this, this is the big problem that every build system is going to have. Because if you create a new one, then the first question people are going to have is like, does it generate Visual Studio projects? Does it generate Xcode projects? And then there's Eclipse, and then there's QCreator, and there's all these sorts of things. working on is this unified representation where an IDE can integrate with any build system.

There's a tool called Meson Introspect, and then you can use that and then it will give you in JSON format all the important bits of your build. So like which files to use, which flags to use, what tests are, how you run them. And then the idea is that I worked this together with one of the Qt creator developer guys, which will be as hunger. He was also a guest.

So he didn't have the time to actually put it in Qt creator, which is unfortunate, but it's the way these things go. But we have this specification, and it's the hope that people will start using it because then you decouple the project definition of an IDE from the project definition of the build system

and have them talk in this common language, and then you can mix and match any way you want. So are you familiar with CMake's ability to export its compile commands as JSON? So that's the compilation database for it? Okay, yes, yes, right. Yeah, so we export that as well. Okay, I was wondering if it was similar to that.

The thing is that for that, it only lists the command lines that you use to compile CFPB files into object files. And it doesn't have any of the rest, like unit tests are these, and targets are these, and this target contains these sources, and so on. Wow, okay. Yeah, that sounds pretty handy. Okay.

So what are some of the other key features that separate Nissan from other build systems? The main thing that was originally what prompted to do it was usability so there's kind of like an analogy to the iPhone because when the iPhone came out, it didn't have that many new things but what it did is it took all of these existing things like app stores and applications and

touchscreens and everything and put them together and made them work together so it's a very seamless thing that works as one this is what the original goal was and still is provide this very simple very streamlined way

you can just say build me this thing, and then you don't have to care about all the nitty-gritty details. And the other thing which then came up, after I've been working on it for a while, is that this naturally grows into a dependency manager. And this is like the forever problem of C++ is that people complain, so we really need a dependency

manager and dependency provider. And the way this works is that in Meson, when you have a definition for a project, then you can take that and use that as a subproject in any other project that you have.

And then it runs it in a sandbox, and then you can just go in there. So if you have a library that you depend on, you can just say, get me that and compile it as part of this project. And it looks like as if it was a part of your project. And once you have the build definition, then you can use it on any platform, like Windows or Linux or whatever. So the idea is to make build definitions composable.

It's like you take these bits, put them together, and then you have the whole. Interesting. So do you already have a library of existing build definitions for common projects? Yeah, so this is something we're working on So this is called the WRAP database And there's like a few dozen of these things like ZLib and LibPng And these sorts of things

If you're familiar with the way development in Linux works, is that if you want to use some sort of library, let's say libpng, then you say apt-get install libpng-dev, and then the system downloads all the stuff for you, and then it's fine. So what we have is called wrap tool. So basically, it's just say wrap tool install libpng, and then it will go out to the central server which then

downloads the original source file and then a zip file which has the build definition on top of that. And then downloads it, extracts it, puts it in your source tree and then you can just build with that. Very cool. And one, so think that when you have

this then you get to do interesting things. As an example, so if you want to ship something with Linux, then you need to use the system libraries, because otherwise you don't get packaged into the actual archive. And there's good reasons for that, and it's pretty nice. And the way the system works, it's very easy to toggle between the dependency that's coming from the system as opposed to building it yourself. Your build definition doesn't change.

It's exactly the same. It doesn't matter where it comes from. And then on the other hand, like the extreme other end of the spectrum, you have something like iPhone. Now, on the iPhone, what you need to do is you have to statically link every spectrum, you have something like iPhone. Now, the iPhone, what you need to do is you have to statically link every dependency that you have into a single executable. And you can't have any shared libraries or anything else. So in MESEN, there's a target where you specify, it's called a library. So you can specify globally whether that should be a static library or shared library. And then you toggle one switch, and then you get statically all of your dependencies are compiled in static libraries,

link, get one executable, and then you can ship it. Okay, interesting. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. Do you hate it when your customer finds a bug in your code? Tired of spending ages trying to reproduce intermittent failures? At Undo Software, they know that debugging C++

can be hard. That is why their next generation debugging technology for Linux and Android is designed for C++ users and is proven to reduce your debugging time by up to two thirds.

Embed live recorder within your program so that you have a complete record of your program's execution in production. Activate it in your test suite to solve intermittently failing tests and replay it later for offline analysis. Memory corruptions, resource leaks, race conditions, and hard to find bugs can now be solved quickly and easily. Visit undo-software.com for more information and start fixing bugs in minutes, not weeks. I watched your making build systems

not suck talk, which I really enjoyed. I was wondering if you could talk a little bit about the incremental build speeds. This is perhaps the most important bit of any build system because whenever you're waiting, you change your code, then you start compiling

and then you're just idling until something happens. So the faster. If it takes more than 10 seconds, then you probably go to Facebook and then you lose your productivity. So this is very important. So we spend a fair bit of time

optimizing for this. One of the main things is that we use Ninja, which we mentioned earlier, which makes the thing very fast. But another thing that we have is something called the link optimization. And this is stolen from LibreOffice, doing the exact same thing. And they stole it from the Chromium team. So basically, what this boils down to is that usually you have a shared library that you build, and then you build something like 20 different executables, like test executables or something, that use the shared library.

And then you start debugging, and then you change your shared library, the implementation of it, but not the interface. So then you type make or ninja or whatever. Now what traditionally happens is that the dependency graph says that your executables depend on the shared library. And the shared library changes, so it needs to relink everything. But the thing is that you don't need to relink if you don't change the interface. If you change the implementation, then it doesn't matter because when you actually run the program, that's

when it goes and gets the code from the shared library. So what we do is that we extract the list of symbols that get exported from this executable or shared library, and every time it gets rebuilt, we check. If the list of symbols hasn't changed,

then you don't have to relink the executables. Okay, that's smart. Do you just do that with like an object dump or something to check the symbols? Yeah, basically. Okay, interesting. What other speedups are there that are worth mentioning? So what we aim to provide is support for all the things that people are using.

As an example, for precompiled headers. So there's an implementation for precompiled headers in Meson that works on all the three platforms of major compilers. And basically what you do is you say, okay, for this target, my precompiled header file is that one over there and then everything else happens in the background and on my blog I did some tests on the Raspberry Pi 2 and if you compile with so Qt 5 code with precompiled headers it it's a lot faster.

And then it gets faster the slower your machine is, obviously, because you don't have to do all the reparsing. And another thing which is very popular among game developers is something called a Unity build. So in a Unity build, you don't compile your source files one by one, but you create this super file, which just includes, hash includes, all of the other header files. No, not header files, the source files.

Then you just compile that. And this seems like terribly wasteful, but the thing is that you only parse all the system headers once, and you generate the code for your std vector int only once, and the speedups can be quite dramatic. So as an example, for during development, I always took these existing open source projects, and then I converted their build systems to Messenger

to see that it does all the things that it needs to do. And I took Qt Creator and I rewrote that. And I think the build times for Qt Creator on a laptop I had a time of something like 15 minutes. And then if you change it into Unity build and build from scratch, it took two minutes. Wow. Now, the obvious downside is that if you change one file, then it's always the full two minutes because of the same time for each target.

So if you have lots of incremental changes, then you want to do the incremental builds because that's a lot faster. But this is something that's used quite a lot by game developers and some other people as well. So I would think there would be limitations with a project like Qt Creator being very large. So if you did a Unity build that your compiler would start running out of RAM or something. So the way the Unity build works is that it's not one compiled project for everything.

It's one compiled process for each top-level target. So one executable is one, one shared library is one, one static library is one. So it's still parallelized, and it's not that huge. Now, there are some other problems with Unity builds as well. So as an example, if you have a static function in some file and the same named static function in another file, then they will clash, and you get these sorts of problems. And it's not for everyone, but those people who need it, it's, like, really nice.

And these are Unity and PCH are things that Mason can support with just the flick of a switch? Yep. Wow, that's neat. I'm not aware of any other build system that can do that. QMake has some sort of support for precompiled headers, but I haven't looked too much into it. But what I do know is that there's a bug report on the CMake bug tracker about add support for precompiled headers in the CMake.

And the reply that they give is that we're not going to do that because we feel that we've given people enough tools that they can write themselves, and it's difficult to create an interface for general use and so on. And as a result, if you look at this bug, there are about

10 different pre-compiled header implementations, as with CMake macros that are linked and attached and everything. And the problem is that they don't really work. Because it's really hard to... Okay, so they work, but they're not

very reliable. There's a problem that's really hard to make reliable after the fact, but if you are inside the build system, it's like, yeah, it's not that difficult. So in Mason, Bill, how do you specify what headers go into your precompiled header? So you write a header file. It's usually called your target underscore pch.h. Then you put your stuff in there, and then your build definition says, okay, for this target, that's the precompiled header to use.

And you just sort out the details? Yep. I like that. Seems very easy to use. Do Linux developers not frequently use precompiled headers because of the lack of support outside of Mison build? So GDC has had precompiled header support for ages, and very, very, very few people use it.

The main problem with this is that a lot of people are actually using auto tools, and from what I could tell, under auto tools, supporting pre-compiled headers is impossible because you can't get all of the state information from the guts of the system. I don't know for specific, but this was the thing that I last looked into.

Lots of people use CMake. You can get precompiled header things, but it's because it's not built in. People are not using it as much. And they're basically just killing polar bears because of all the electricity that gets wasted. I will say from my experience, I've seen it used very rarely on cross-platform projects.

Yeah. Because supporting it consistently across all platforms is painful. Yes. So do you know of any large projects currently using MisenBuild? I'm not aware of any large projects currently using it. What I do know is that there are some projects inside companies where people are using it, but they don't talk about those. I don't know how big they are.

But one example which is coming, hopefully soon, is the GStreamer project. So they've been looking into using Mesen build, so they're evaluating it. We have a trial version of GStreamer that compiles with Mesen.

But they're currently busy with their release of 1.6 or 1.8, the next version. But I would imagine that they're going to do some sort of decisions on what they're going to do about it in the near future. Now, MisenBuild is not just for C++, right? It supports other languages as well? Yeah, so C, C++, Fortran, Rust, Java, C Sharp, and just last week that we added Swift support.

But the thing is that C and C++ are the ones that are actually battle-tested. The other ones are not that they work, and you can use them, but I wouldn't be surprised if you find bugs. It's just the question of not having enough users. The kind of use case I personally have for multiple language support in a build system is if you're building a C++ library that has Swig-generated wrapper bindings, and then you need to also compile the Java wrapper binding interface and be able to test that, and the C Sharp, which is hard also. So that would be something feasible?

Can you have multiple languages in the same build project? Yeah, so compiling stuff like multi-platform for Android is something that wasn't originally, so that's why the Java support was put in there. So if you are a 100% Java project, you probably don't want to use Meson. But if you are mostly C++, and then you have this shim of Java,

then it might make sense. Okay. So how hard is it to add support for new languages? So it's not terribly difficult. At least for me, it might be for other people a bit more difficult. But the commit that added Swift support, which was last week, although like a series of commits,

in the end, it was about 400 lines of code. So the method is implemented in Python 3. So that makes it a bit easier. But it's not that much. But this, of course, is preliminary Swift support. So you can compile and engage static libraries, and then you can combine C with C code with Swift,

and then you can compile a Swift code that generates Swift code that then you compile into another project. So the basics you need. All right. Is there anything else you want to tell us about Mezzanbill before we let you go? It is open source, source right so you're looking

for contributors yeah i'm happy to have contributors so one of the things which does come up is that people are writing new programming languages and usually what they do is that they write their own build system for that specific one because because then you can optimize it. Usually whatever method you come up with is simpler than the way C and C++ are built, so you might want to put your own build systems there. But on the other hand, you might also want to consider taking Meson and adding support for that. The reason for this is that when you have a programming

language and then people start using it one of the first questions that then comes up is that how do i compile use my existing c libraries with this thing and then you get all the same problems is that okay so you need to have this way to build C as part of your build, and it gets very complicated very fast. And it's because if you want to provide binaries on Windows, then you need to build all of your own source and so on. And so there's like a simple phrase for this, is that C and C++ have a dependency manager problem, but unfortunately every other language in the world

also has a C and C++ dependency manager problem, but unfortunately every other language in the world also has a C and C++ dependency manager problem. So this is something that people looking for new programming languages might want to look into. Okay, I'm curious. This is maybe a bit of a diversion, but you are a C++ developer yourself. Yes.

And you implemented your build system in Python three, correct? Yes. Let's talk about your decision to choose Python. So there was a specific reason for this is that Python for certain size projects is extremely productive. And if you do mostly string manipulation and arrays and stuff, that's what Python is really good at. And for C++, now it's gotten a lot better recently

because you have all of the wonderful tooling that you have. But it's still not quite as nice. But the thing about Meson is that it doesn't expose Python 3 in the build definition in any way. So if anyone wants to re-implement it in any language that they choose, that's totally fine, because the specification is clearly set up so that the Python parts are completely hidden. Okay. So is it safe to assume that Python is a dependency, or do you have some executable

that wraps up your Python dependencies all in one place or something? Currently, the Python tree is a dependency. We'll probably need to create a Windows installer which has all of the things, executables in them. I've seen some people do that with Python projects, but I'm not terribly familiar with it

myself. The other thing, why Python was a good thing, is that Yeah, I've seen some people do that with Python projects, but I'm not terribly familiar with it myself. Yeah. So the other thing why Python was a good thing is that, if you remember, there was the RAP database. So what we need is stuff like parsing JSON and sending HTTP requests and all of that stuff. And Python is really good at those. It is very productive at those things, yeah. Sorry, I didn't mean to interrupt.

It's just like it's a faster way to get it working and have people try it. And then if it turns out that this Python is some sort of huge bottleneck, then we can fix it. So if you could pick one thing from Python to put into C++ and just

narrow it to one thing, could you? Could you narrow it down, and what would it be? The thing that I really like about Python is that you can have an arbitrary object thing and then serialize it with one command. And it's used quite heavily, the pickle module. And it's really, really nice because you have these dictionaries of stuff, and it's like, I don't want to write these serialization things,

I just want to put it in the file, and then I can do that. And it's really, really nice. Okay, cool. I'm fairly certain that's not going to be in C++ ever because of the way this works. Well, it might be plausible if we get reflection support someday. Maybe. Well, where can people find you online and find more information about MezzanBuild? So MezzanBuild is at mezzanbuild.com

and there's links from there to GitHub and all the usual places. I'm reachable on Twitter. My handle is at jpakkane. The last N isn't there, but just go to the website of the CppCast page and have all the links there. It's a lot easier

than me trying to explain the Finnish type ways to write things. But you can find links in there. Okay, awesome. Well, thank you so much for your time today, Yussi. Oh, it was a pleasure. Thank you.

Thank you very much for joining us. Okay, we can all turn off our recordings. Thanks so much for listening as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, I'd love to hear that also. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.