CppCast - Meson and the Meson Manual

Episode Date: March 19, 2020

Rob and Jason are joined by Jussi Pakkanen. They first discuss the ongoing effects that the Corona Virus is having on the C++ Community. Then they talk to Jussi Pakkanen who gives them an update on what's changed in Mesonbuild since he was first on show 201 episodes earlier. Jussi also shares some info about the Meson Manual which is available as an e-book. News C++ Events affected by Corona Virus asm-dom Deleaker review Links The Meson Build System The Meson Manual use coupon code: cppcast2020 "Behind (and under) the scenes of the Meson build system" - Jussi Pakkanen (LCA 2020) Sponsors PVS-Studio. Write #cppcast in the message field on the download page and get one month license Read the article "Zero, one, two, Freddy's coming for you" about a typical pattern of typos related to the usage of numbers 0, 1, 2

Thank you. In this episode, we discuss Corona's effect on the C++ community. Then we talk to Yussi Pakkanen. Yussi gives us some updates on Nissan Build and the Nissan Manual. Welcome to episode 239 of CppCast, the first 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? I'm doing all right, Rob. How are you doing? I'm doing okay. I don't want to go over Corona stuff every week for the next two months, however long we're going to be in this, but I feel like we should mention it briefly because it's

kind of really starting to pick up here in the US at least. It's starting to become a concern. Well, at the very least, while we have this in the news items later, we're going to try to keep everyone apprised of anything that is affecting the C++ community. Sure. But you have any news yourself on that end? Are you okay? Family keeping safe? Everything's fine here. I just thought it was interesting because I thought I would just mention this. My sister, the school district that my sister has her kids in, is one that about five years ago was set up in a pilot program

to do online school when they needed to. Oh, so they're fully prepared for right now. They're fully prepared for it. That's been a normal part of their lives. If there was going to be a snow day or a bad weather day for some reason, they just flip the switch and everyone does school remote. They literally never miss school for a disaster or whatever. And it comes up, you know, where they live, they've got a few snow days a year or whatever, but they just do it remotely. So it's to the point that like, if you're someone who can't afford internet access

or a computer, they have Chromebooks that they issue to all the students. They've got Wi-Fi cellular hotspots that they issue to the kids who don't have Wi-Fi at home and school just keeps going. So to them, no big deal. That's great. I will say my uh county here in north carolina was a little delayed on deciding to cancel they kind of they waited until i think saturday or sunday afternoon before they officially called it um we were prepared a week after a lot of other areas yeah yeah and and several other counties and the state had already called it by then they were definitely one of the last ones to go but we were already prepared to keep the kids home just you know to play it safe so i'm glad they finally did make the right call and they're still trying to figure out things like how they're going to teach the

kids online because they're definitely not set up for that currently yeah i think they're probably my sister's school district is i i would say likely very unique definitely in the u.s maybe in the world i don't know that they're so fully set up for it. Hopefully after this, more schools follow suit with that type of program. Right. Okay, well, atop our sort of like treated piece of feedback, we did get this tweet from Victor Bogato saying, CppCast, quick question about the episode we had recently with Barry Revzin.

I didn't catch it correctly. The generalized pack expansion, is that on C++20 or on track for C++23? That's proposed for 23. Yeah, that's a proposal for 23. We talked about a few things with Barry. He worked on a bunch of changes to improve the spaceship operator, and those all made it into C++20.

And we also talked about some proposals he has including the PAC declarations and what was the other thing we talked a lot about? There was one other thing I think that's coming for 23? Oh, the pipeline. We talked about the pipeline stuff. Okay.

Thanks for reaching out with us, Tweet. We always like to hear your thoughts about the show. You can reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. And joining us today is Yussi Pakkanen. Yussi is the original creator and project lead of the Nissan build system. This has led to many interesting things, such as people coming up to him at conferences to compete in who has the most terrible build system setup inside their corporate walls. His prior work experiences range from desktop Linux to mail sorting, mobile development, slot machines, and computer security. His hobbies at the time of

writing include sitting at home waiting for the coronavirus lockdown procedures to end. Yussi, welcome to the show, or welcome back to the show, I should say. Well, it's good to be back. Maybe for some context, since you listed your hobby as waiting for coronavirus to pass, where do you live? So I live in Finland. Okay. And they closed the schools here, I think, today. So yesterday was the last day when the kids were allowed to be at school.

But other things like this, there are no meetings of more than 10 people and so on. But I think that's pretty good. So today I went to the nearest mall to buy up some supplies which included a PlayStation 4 and

it was actually kind of nice because there was no rush, there weren't that many people, you can get to the stores. And everything was pretty good. All things considered, right? So no concerns for you at the moment. You're just going to play a bunch of games until things pass over? Well, so I used to work remote, like 100% remote for a few years.

And this is very much reminiscent of that. So there haven't been panic purchases of people emptying the stores or any of that you might hear on the news. So for the moment, things are working pretty well.

That's good. Yeah, we'll say overall as an industry, we're very lucky in that most of us are already pretty well equipped to work from home. A lot of us might either work from home already or we can just grab a laptop and take it home. So that's good. Yeah, 10 years for me now. Yeah. Yes.

So I'm a consultant. So my current customer has had a thing for many years that consultants are not allowed to work remote. And this is a decision made by someone some time ago, and you cannot watch from this. And suddenly, when this thing happens, it's like, okay, so you just work from home. I mean, we changed our mind.

It's fine. Yeah, it's fine. So this is the second day that i'm doing this now and and i remember the like the best part of working remotely is that you get two extra hours a day because you don't need to travel so that's that's really nice yeah when you just have to walk down the stairs for your commute or whatever that's nice yeah okay well you see uh we got a couple news articles to discuss. Feel free to comment on these and then we'll start talking more about Mison and the Mison manual that you worked on.

Okay. Right. Sounds good. Okay. So I promise this will be the last mention of Corona for this episode. As Jason mentioned, we have this list of C++ events that were affected by the Corona virus that Bryce Lollbach posted on Reddit.

And yeah, lots and lots of conferences have postponed or just canceled their conference completely. I think we were talking last week about whether or not C++ Now was going to make a change, and they did decide to cancel that conference, which was going to be in uh in may um and yeah lots of others uh cute day conan days accu c++ russia um so far it's cpp cppp yep so far it looks like pretty much every conference that was taking place over the next like two or three months has uh has decided to postpone or cancel hopefully the one the one for like the fall will be unaffected uh so c++ on c uh phil nash's conference um is still scheduled for june 7th through the 10th and if you go to the website just under three months away right and phil has listed it as

uh tickets are currently um ticket sales are currently paused. Okay, so he's making a decision. So he's made no changes, but he's being cautious, I guess, at the moment. That makes sense. Now, I made a comment on Twitter, and I will stand by it, I think. All of these conferences that are doing 100% refunds, I know that these conferences, and we've had many of them on here, they run on very tight budgets. They're not big profit making things necessarily.

So I suggested that if the conference needs to get canceled, I personally think it's okay for them to keep 5% of the ticket price or something so that it doesn't bankrupt the conference. If that would make any difference at all maybe it wouldn't make a difference maybe it's too little money i don't know i i would hope that um you know the venues or whatever other costs that they would accrue would be able to work with them and they'd be able to get that money back so hopefully they're not out much money if any at all and that part i have no idea i mean for people who already started printing all their supplies and everything it could be a significant

amount of money could be uh the other thing i wanted to mention though is we we talked about the conferences but there is a 2020 iso meeting that has decided to cancel the one in varna which was going to be uh in june i believe um i wonder if they'll look into doing like a remote meeting or something like right now they're just saying canceled but uh i mean is that going to possibly like delay the next standard or just mean less goes into it the official word is that it will not delay C++ 23. That has been stated. I can't give you a link at the moment. It might

mean less goes in. Yussi, do you have any thoughts on this? Were there any conferences you were planning to speak at that were postponed or cancelled? There was going to be a build track that was organized by the Bazel people in New York in May. And I submitted a talk to that, but then they canceled that.

So maybe sometime later. Maybe there should be something like an online conference. Something like that. So like have something where you have people talking and all the talks that aren't being held at conferences could now be online, maybe. And that's a really good point. Yeah. Something we don't have any news items about on here, but if you're following things on Twitter and on Reddit, you will see that a lot of users groups are doing things like coffee get togethers or drinking via Skype or whatever, hanging out and chatting. And a lot of meetups are going fully online as well at the moment.

So there are things to keep your eye open for. Yeah. One thing just on that note, I saw that Discord, which is a chat tool that has a good video service built into it. I think they had previous limits of only like 10 people for a video conference. If you were just using the free membership, I believe they increased that to 50. So if you want to have a big conference with a bunch of friends or coworkers, you could do that on Discord.

Okay. Next thing we have is ASM DOM. And this is a library on GitHub to build a minimal web assembly virtual DOM for a C++ single page application. And definitely not something I've used before. I don't really do much web development, but I thought this looked interesting. Part of it broke my brain. Did you all look at the examples for this? Yeah. I've done some

work from this, and the big problem is getting to and from the browser, because the actual interface between WebAssembly and the browser is just integers, if I remember correctly. Possibly strings. And you have to build everything up from atoms.

And if you look at the examples, it's basically kind of like JavaScript within the C++ way. So you have when this is clicked, you have lambda, and then things happen. And the thing that I think is going to be really convenient for is that if you want to create an application that has a control interface, which is a website, so you just have a web server and you connect to it

and you can do things. And with these sorts of technologies, you can do a fairly good thing when you have your website. Web page is the control interface. So it's kind of like a gree thing toolkit for for very simple uses yeah and the examples i mean from basically like what you said uh it's difficult to describe but it really does look like javascript integration they've got like div tags with an on click attribute and then a c++ lambda in there and that's the part that made me go okay that's

weird it also made me go i want that because i'm currently working on a project that could have used things like this ah well are you gonna try it out yeah um probably not at work okay maybe maybe for fun right it says that you needs uh it uses gccx to do this and i don't know what that means i don't oh there we go okay so it has some other processing project or something that lets it do that oh yeah what is the transformation tool interesting okay okay uh next thing we have is an article on the coding tidbit blog and this is the a review of a tool called deleaker which i have not heard of before but it's a windows-based um memory profiler it's supposed

to be very good at detecting memory leaks um and it looks like it has pretty good support for both c++ and c-sharp and and mixed applications that have both, you know, C sharp and C plus plus together. So it seems pretty powerful and you don't need to, um, you know, rebuild with any specific tooling or anything. It just hooks into your, uh, hooks into a debug build. Okay. Any changes? Can you say something else, Jason? I was just going to comment that it's windows only at the moment. Yeah, it does look like it's windows only. But if you are on a Windows platform or if you're on a cross platform, it looks like it's a pretty good tool. You've done this kind of thing before, right, Rob? With C Sharp and C++ in the same project?

Yeah, I do. And that's what my primary job for work is, working on a mixed C Sharp and C++ application. So I might look into this myself. How often is it that like, say, reference counted or garbage collected C sharp objects somehow cause a problem in C++ land because something is destroyed when you didn't expect it to be or vice versa? I don't run into that very often, because I think we keep a pretty thin layer and try not to like passsharp objects down into the C++ land. Do you have any thoughts on this one, Yussi?

I don't really do Windows development, so I don't, but more tools is better. More tools are always better. Use all the tools that you have for finding bugs. Okay, so we did have you on the show, but it was 201 episodes ago when we first had you on to talk about Mison build. And this might be a loaded question. But

do you want to maybe start off by telling us what's changed in Mison build since we last had you on like four years ago? Okay, so the biggest difference between now and four years ago is that we have actual users. And actually quite a lot of them, and fairly large projects. So some of them include stuff like Meza, which is the 3D graphics stack on Linux. So if you're watching this or listening to this on a PC that runs Linux and you see graphics on the screen,

it's probably built with Meson, the entire graphics stack, so the OpenGL stack and the Vulkan stack and all those things, and all the user-based parts of the drivers. And there are a bunch of other things, such as the GStreamer, which is the big multimedia framework.

And I know that there is a commercial application that's being sold that's a mix of C and C Sharp. So exactly this which is using GStreamer for, I think it was a video conferencing application. And there's a bunch of other things like the Corn

Shell, which is one of the original shells from Plan 9 or even earlier. And this has the record of being the biggest build time boost ever, because when they switched from their make-based thing to Meson, it got 35 times faster. Not 35%, 35 times. Where did that come from?

So they explained it to me that they had some sort of software development platform thing that came from Plan 9, which was developed in the 80s and was make and magical things. And no one can understand what it was. And then they just threw it all away and built it from scratch. And this thing has actually happened to me several times, is that when people convert their old projects into Meson and then they compile them,

they don't believe that it actually compiled because it's so fast. So there's lots of easy gains to be had if you have one of those very old make-based things. And one thing which I found out was just like last week is that there's a project called OpenTitan, which is kind of like a root of trust for processors. So I read the website,

but it's kind of what they do is that they have a special chip that verifies the boot ROM for CPUs and they want to have a full tool chain where you have everything from beginning to the end so you can trust your silicon. And it's based on the

Google's Titan chips that they have. And this is built with Meson and they combined that with building the Verilog and all those things, which is kind of cool. And so on. And there's a Picolipsy, which is C library, created by Keith Packard. And he's building it for his work on RISC-V. So there are like 28 different versions of RISC-V if you count all the combinations of things that you can have in your processor. And he builds all 28 versions of the C library

and runs all the tests with them on QMU. Wow. In a single Ninja invocation. And he showed it to me earlier this year. It's like, this is actually kind of cool. And there are commercial projects, and there is a company that uses it to create firmware

for lasers. I am not aware of anyone using it with sharks, but if someone out there knows, let me know, because I want to have both sharks and lasers. That's a good combo. Yes. So that's the biggest change. So the core of Meson hasn't really changed.

You write your build definition and so on, but it's mostly been polish. And polishing always takes 10x the amount of time to create the actual core. And that's basically what we've been doing. I recently had to build a project that was autoconf-based, and it had been doing. I recently had to build a project that was autoconf based, and it had been so long since I had done that. And I had forgotten how it had to,

you know, it does the detection of all the features, and then again, and then again, and then again for each sub project. And yeah, I just thought about that when you're talking about this 20 times performance boost and building and how people don't believe it compiled. I think I can see that if they're moving from autoconf and make and such. Yeah. And this is particularly bad if you are on Windows, because configure scripts on Windows run even slower than they do on Linux. So GStreamer had a thing where they had a full build of their thing, a daily build. And on Linux, it

took about an hour. And compiling it on Windows took more than a day. So you couldn't have a daily build because it took more than a day to build. And then they switched that. It's about an hour now as well. And that was Configure's problem, effectively. Mostly, yes.

And there's a special thing for get text because it compiles itself several times and then does something weird, I don't know. But it's very slow. Right. Get, yeah. I feel like I'm so glad that I've moved beyond most of those old build tools now.

All right. Okay. So in January, you just released the Misan manual as an e-book. Do you want to tell us a little bit about that and what motivated you to write an e-book? Let's start with something special for all the UCP

PCAST listeners. The manual is available for purchase at misan-manual.com But for Manual is available for purchase at meson-manual.com. Okay. But for one week after this podcast goes out, you can use the special code CPPCAST2020, and that gives you 10 euros of the price. So it's until the Friday of next week.

Is that like all uppercast, CBBCast, 2020? Any spacings or dash? No, no, it's just lowercase. And all together, no dashes. Gotcha, okay. All right, so the main motivation why I wrote it was pretty much the same motivation I had for writing Nissan in the first place, which is that I felt like doing it,

which is usually a good reason to do anything. And then there was a different goal, which came in later, is that there's been a lot of talk about how to compensate people who are developing and maintaining open source projects for their work. And just sending money from one country to another for no reason is difficult, and there are tax problems, and it gets very difficult. But then, like, if you sell an actual product,

there's established conventions on how to do that. And then, like, okay, so here's an e-book that you can buy, and it's very easy. if you want to get your company to buy it. People know how to do that. And it's very simple. And all the money problems and things,

these are solved problems. So as an experiment, could this work? Could this be a way for people to contribute to the maintenance of free software projects. It was an experiment. Let's see how it goes.

So how long has the book been for sale now? It was published at LinuxConf Australia, which was in January. So about two months. And in this time, it has sold about 60 copies, I think. So not massively.

So the big problem with selling anything is marketing and exposure. It's like, how do you even get people to know that this is a thing that you can buy? And advertising is always difficult. So like, how to get the message out there, so to say. Right. Okay. Well, listeners, yeah, if you're interested in using Misan and want to support the project, you should definitely check out that link and share it around.

So what do you hope users of Misan will get out of the manual that they can't find in any existing documentation you might have had? So the existing documentation that we have, it's kind of heavily, it's wiki-like, let's say. So there are pages on things, and then you read them, and you understand, and then there's copies. If you want to know how to use this in an actual project, look at this unit test in Meson's test directory because there's a sample project that does that.

Right. But the book itself is actually, it's written and edited like a book, so there's an actual narrative, and there's background information on how compilation works, and how course compilation works, and what are all the different terms that go

there, and maybe I sent you a copy of that, so if any of you, either of you have read it, maybe you can comment on whether that's actually been successful. I didn't have a chance to read through the whole thing, unfortunately. Well, parts of it, yeah.

But there are things like, have you ever considered how, wondered how shared libraries work? So they're symbol names, and how are they actually resolved? What happens at runtime, why things happen the way they do or like why do you sometimes need to have the same

static library multiple times on the link line on some compilers but not others or otherwise your thing fails and these are the sorts of things which are explained there and this, it was like quite difficult things like what should put in the book and what should be on

public documentation because like if people get the feeling that they're like I've gotten comments from people saying that this is bad because you're a paywall in documentation and then like you don't like the fact that it's not all out there freely available so

it's a balancing act on what to put in the public documentation. So the idea is that just reading the website documentation is enough that you can do anything that you want. And then if you want to know more detail and their sample projects and things and so on, and explains on why you would do certain things

in a certain way. And that is what things are mentioned in the book. So it's not just about MISAN, but also about understanding how build systems work a little bit in general. Yes. So at the moment, it kind of seems like CMake has become the de facto standard. Do you want to give our listeners a reason why they should be taking MISN seriously right now? So I get this question quite often.

I'm sure you do. And you can go into lots of detail about the technical detail of which things are done better and so on, and why string typing is not a good thing and so on. But I'm not actually going to do that. So instead, I'm going to tell you one of the most common comments people give me when they meet me at conferences and they tell me that they're using it. And what they tell me is that when you're using Mesent to build your software, it feels nice.

Okay. That's like, yeah, that was kind of the point. It's like, you have a task, you need to do it, and it's like, oh, it did what I expected it to do. So it's kind of like, so this is the thing which we have spent a lot of time and effort on, like, how do we get UI UI and user experience so that the things that you want and need to do happen almost automatically? And you don't feel like you have to battle against the tool.

So at work, I had this problem today is that I need to pass they're using CMake and I needed to pass a define that has a string in it so dash D quote, oh this backslash quote and how many levels of quotes do you need

to get this to happen and it's like in the event I just gave up and I just wrote the stringify macro everywhere that I needed it. So I didn't need to put in the quotes in the thing. But so in Meson, command lines are not lines. They're always string arrays or arrays of items. And then when you have that, then things are simple, because this is a thing, it's like

it's a dash d whatever and you just write it and the backend takes care of passing it through whatever eventual backend system you might have and does all care of all the quoting because an array of strings is a higher level of abstraction

than just plain string right I want to interrupt the discussion for just a moment to bring you a word from our sponsor is a higher level of abstraction than just plain string. Right. I want to interrupt the discussion for just a moment to bring you a word from our sponsor. This episode of CppCast is sponsored by the PVS Studio Company. The company produces the same name, PVS Studio Static Code Analyzer, that has proved to be great at the search for errors

and especially typos. The tool supports the analysis of C, C++, C Sharp, and Java code. The article 012 Freddy's Coming for You, which has been recently posted, clearly demonstrates the analyzer's outstanding abilities of searching typos. The article shows how easy it is to make a mistake, even in simple code, and that no one is immune from making it. You can find a link to the article in the podcast description. There's also a link to the PVS Studio download page. When requesting a license, write the hashtag CppCast and you'll receive a trial license for a full month

instead of one week. Do any IDEs work well with Mason? I know over the past few years, CMake has gotten a lot of integration, especially from Visual Studio. If you're using Mason, is there any

ID integration like that? There's some. The Eclipse CDT has it. The best integration that I'm aware of currently is in KDevelop. They have...

The thing is that what we have done is that we export all the data that we have about the project and how it's set up with a tool. And you can get it as JSON. So basically, you can query that list of all the targets that are going to be there. You get all of the compiler flags that are going to be used for this particular target. You get that. All the tests, you get all of that. All of the compiler flags are going to be used for this particular target. You get that. All the tests, you get all of that. And then if you want to write an IDE plugin, then you don't have to go parsing inside of our Meson build definitions.

You can just slurp all the data with standard JSON thing. And KDevelop was the first IDE to add full support for that. Originally, I talked with one of the developers of QCreator of how this should be exported. Because in IDEs and build systems, there's the M times N problem. You have M editors and you have N build systems, and then they all need to understand each other.

And it doesn't work particularly well, because it's just a lot of code to write and to maintain. So then it was like, okay, let's do this in a way that's actually so IDE people can use this quite easily. And I think there is a plugin for CLion made by some guy. I don't know the specifics about that, but it integrates with CLion. I had a chat with the JetBrains developers at CppCon, I think. And like, hey, now you can write your plugin for this. But then they say, no, no, you write your plugin for us.

And the discussion went around in circles. And they're like, no way, we don't expose that information yet, so you can't write the plugin. But this is like a... It's a big issue. It's like, when you are a small player,

like the tool, how do you get other people to use your thing and support? And because people writing IDs, they obviously prioritize their work based on their existing users and what they want. And it makes sense for them that, okay, this might not be interesting for us yet, but if it gets popular, then we can add support for that. But it's not going to get popular unless people add support for that.

So it's the good old chicken and egg problem. But things are getting better. So the Static ADD develop thing, and we know now that we can expose all the information that we have in easy-to-parse JSON, and then people can use that to actually write their integration. Previously, it existed, but we hadn't backfield tested it. But now we do.

So this output file that you're creating, is it any kind of standardized thing? I swear that there was some discussion several years back about standardizing this kind of interchange between IDEs and compilers and build tools, but maybe I'm misremembering something. So the idea that, so this was a came about at the same time as there was the CMake language server. Right. And people wanted to add that. And then I looked into that. And if I remember correctly, the CMake build server protocol is very heavily tied into how CMake is set up. So it speaks of things in terms of what they are in CMake, as opposed to

what they are in the abstract. And in this case, what we wanted to do is to write basically a JSON specification that could be a standard. So we try to keep everything that's like, it's an abstract description, not about how Meson works internally. So if there are people who want to standardize these sorts of things, maybe take a look at that

and use that as a basis. And if there's any changes that you need for that, we'll be happy to add them. Because this is a thing which would be of general use. Because then if you want to create a new build system, you just write this JSON intermediary and then you can use all the tools. So on this topic of, you know, IDEs and Mison and stuff,

it made me think, like, do you... What's the story like if I've got some library that i'm currently building with cmake and i want to build my executable with mason um how do i like to can do these things tied together how can i call cmake i don't know you know what i'm trying to ask yes so um this ties into a larger problem of you have two different build systems and you would ideally want to run them at the same time in the same build directory. So you have one called the other. And this is a thing which people really want and it seems simple, but it's actually incredibly difficult.

And I don't think that it's possible to do reliably in the general case. Now, that being said, we have integration parts for CMake on different levels. So first of all, what we can do is that if you have a dependency that doesn't provide a package config file, but instead provides just the CMake, whatever the module files are. We can use CMake to extract that information and then use that dependency if it's installed on the system. And we can also generate the CMake file. So if you can build your own thing and install it,

then you also generate the CMake modules needed to use it. So we have that. And then also, in addition, for simple cases, there's a thing where you can build a single project with CMake, and it does all the magic and then slurps out the data and links against that. Now, I emphasize again, this works, but it only works for simple cases.

And because what happens is that if you have your program and then you have a dependency built with CMake, you go, okay, it works. But what happens if you have, if your dependency at CMake depends on something else, which is built with stuff like, say, Mesa, and it's part of your project, you would want to inject your own thing inside the CMake project

so it uses the one that you built. And this is a thing that's not possible. And it gets really, really, really complicated. Okay. And so at CPPCon, I had a talk last year about this issue. And the thing which I mentioned there was that there's actually a really good solution for this problem of mixing multiple different build systems,

which is used in Linux. It's called Flatpak. And a very high-level, nutshell version of that is that in Flatpak, you create a file system that looks like a root file system of a Linux distribution. And then you just install things one by one using the existing thing, because all projects know how to do that. If you have a CMake project, a Mesent project, an Autotools project, that's what they do. They build, they install, and it's usable from the system.

Right. And the thing that makes this work is that there's kernel isolation. So when you are inside the package, you only see what's inside there. And if there are people who care about ABI issues, you could build a completely different ABI inside of this thing. And applications and libraries think they are being installed in the Linux host like usual, but instead they are in this special package. And the thing that then makes this work is that you can mount your home directory inside of this

thing. So you can run it, and all the dependencies come from the package that it's in. But the file system that it sees looks like your home directory. And it can't tell that all the dependencies come from somewhere else. And in this way you build your thing the way you have always built. You just build, install, build, install, build, install all your dependency. It doesn't matter which build system they're using or whatever. They just work the way they always have worked. The downside is that this is Linux only. You can't really do that on windows or or mac um maybe they will add something like this later i don't know but but for linux usage this is it's really nice okay okay uh maybe kind of related to that discussion how well does

mison work with the currently available c++ package managers like Conan or VC Package? So it works quite well with Conan. I had a chat with Diego, also at CppCon, and what he told me was that he's seeing a lot of increase in usage in Meson. And all the integration pieces are there and it's working. And so Meson doesn't really care where your dependencies come from. So if you have a package config file that tells you how to use it, that's all it really cares about.

And then, or if you have like a CMake dependency, then you can use that. Now, Meson also has its own package manager and dependency provider because everyone has to have one of those. And the way that works is that you can define a Meson project as a subproject of your thing, and then you can say, okay, I want to build this dependency. And the way it's set up, or how the system works, is that the build definition file only defines what dependency you want. It doesn't say where it comes from. And if you look at how Conan works, for example, you have to call Conan inside of your CMake lists file.

And this ties them together. But in Meson, it's like, okay, all of that is somewhere else. Inside of your built definition file, you just say, this is how my thing is built. This is what I need. And then as much as possible, the extraneous information is fed from the outside. So the typical use case that we have is that people build stuff like on Linux, you either want or you have to use the system dependencies. But if you are on Windows or on OS X or whatever, then you want to build your own.

In Meson what happens is that you can specify that, okay, I have this dependency, it has this name, and then the subproject is called this name. And then what the system does is that, okay, is this dependency available on the system? Yes? Okay, I'm going to use that and then build against that one. And if it's written version and all that. And if it's not, then it will build it as a subproject. And then you can specify your own dependency. It's called declare dependency.

So you get a dependency object, which then calculates everything that you need to build against this particular dependency. And then it might be the dependency object. It's kind of like basically a virtual base class. It just tells you this is a dependency, this is how you would use it, and then when you pass it somewhere else, then it does all the magic behind the scenes

to either build it or use the existing one. But your build definition file doesn't have to care about this. Okay. I like the approach, the idea that the external dependencies is just a built-in kind of feature. Yeah. And then you get all sorts of things with this. Suppose you have ZLib.

Usually ZLib is required by lots of different things. But whenever you look up ZLib once, then when you call in the subprojects or whatever, whenever someone tries to do a lookup of Zlib again, it will always return the same version. There's only one version of any dependency and it's enforced. That's helpful. Yeah. And for the package management system or dependency provider system that we have, it's called wrap, and it's like wrapdb.meenbuild.com. And it works kind of like Debian. It's that you have your upstream source tarball. And then in addition to that, there's a patch file or it's like a patch zip

file, which has just the mesenbuild files. And then you download both of them, you extract them, and it happens behind the scenes. And you extract them, put them overlay on one of each other, and then you can just use that. And this is a way we can provide native build, Meson build files for projects which don't build with Meson itself. So like zlib, libpng, libjbg, and lua, and there's lots of them available. So like when people say that, and we wouldn't be surprised if in C++ we had something like CargoA, where you just write these things, and it downloads and builds everything.

Well, we do. That's what Meson has done for like three years now. So I would like to point out that the package, like the number of packages we have is not that great. Right. But submissions are welcome. Jason, you had a question? Yeah, so earlier we all agreed that the more tools the better. And one thing I've been wondering about is if Mason can produce

a compile commands JSON file to send to Cling tooling for all the Cling tools that want that kind of thing for running Cling tidy. Yes, if I remember correctly, if you had asked me this question 201 episodes ago, I would have said yes. It's been there for quite a long time. But in addition, what we do is that in Meson, we have a thing called run targets.

And it's basically just a command, and then it gives the top-level name. So you could have something like Clang-Tidy, and then you could just write all the things needed to run Clang-Tidy with your specific setup. But what we do is that if you haven't specified a Clang-Tidy target yourself, and there is a.clangtidy file in the root of your project, we will generate a Clang-Tidy command for you automatically. And the same for

Client Format. Oh, and the same for Client Format. That's interesting. Yes. Do you do the format edit in place, or do you just report if there are things that are mismatched? It's in place. Okay. And this is, again, it's like

the idea is that these are things that pretty much every project is going to have to do anyway. So let's provide them out of the box. And if people want to do their own thing, because sometimes they need to, if they define their own, then we'll just use that. Well, as long as you're going down that road, do you do the same thing for a doxy file.in or whatever that's called? Doxy file.in. For doxygen config files. Yeah, that's what I? For Doxygen. For Doxygen config files, yeah. That's what I'm referring to, sorry.

Yeah, so there's a general thing for generating, configuring files with information like the config.h file. Right. And so that's pretty basic. I don't remember if we have specific helpers for Doxygen or if it just works with the basic.

There's a sample project for Doxygen in the Meson Source repository, so you can check that out if you want. I know people are using that. Just that I'd try since you said it was so magical with Kling Tidy. Well, we don't have magic for everything. No, I would imagine, yeah yeah our supply of magic is limited but it gets replenished every now and then right good uh i saw that the uh nissan manual was based on i think it was version 0.53 uh do you think you're getting any closer to calling it 1.0? It's getting closer.

This is the eventual, like, the horizon problem. It's like, well, we could just add some more. So the original goal that I had, like, first ever 1.0 limit was that once DStreamer uses Meson as the only build system,

then we, okay, now we know it's good enough. Now we can call it 1.0. But what happened was that then people, we got a lot more contribution, a lot more people showed up, and they started submitting stuff. And I have a lot of, it's just keeping up with the pull requests that I get and going through all of them is a lot of work. So this hasn't gone. But another thing which has come up now

and which I wrote a blog post about is that I've been looking into converting LibreOffice to build with Meson. And as far as I know, LibreOffice is the largest open-source C++ code base in the world. I would not be surprised. Yes. So it's about 8 million lines of code. And if you remove the comments and empty lines, it's about 5 million.

And I did some research, and the only thing that I found that was bigger was Chromium. But Chromium is a monorepo so they have all the dependencies in the same repository. So it's probably counting it wrong because it was 25 million lines. Right. And the way LibreOffice is let's say interesting

in that they generate a lot of their code. So in addition to this 5 million lines of code that they have, they generate 1 million more from IDL files. And they do very complicated things where they generate code and generate Java bindings and all that sort of thing. And there are things which you cannot do easily

with Meson currencies. You have to do a bit you have to do some hacks. And the code generation thing is the thing which is not quite as polished in Meson as the other part. So maybe if we can manage to make LibreOffice built, so currently you can build it on Linux and it even runs, you can start it and so on. But you would also need to make it run on Windows and Mac and Android and all the other things.

And they need special things. But I would imagine that if we can pull that out, then there's really no point in delaying the 1.0 anymore because if you can do that, then you can do pretty much anything. Yeah. Yeah. So I just had to check because I know the Star Office,

or excuse me, LibreOffice, which is based on OpenOffice, which is based on Star Office, has a very old code base. And so it's apparently 1985 was when that project was started. So I'm not at all surprised. As you said, their build system is interesting.

Yes. And the entire code base is also interesting because it was owned by Sun. And I think what happened is that Sun used it as a poster child for Java. And if you look at the code and the way things are set up and so on, it's very Java-like. And it's like

com colon colon star, colon colon office, colon colon, and it just goes on forever. And so on. And perhaps not all of the technical decisions made at the time

have stood the test of time. So it's interesting in many ways. I'm sure it is. How far along are you in this project to try to get LibreOffice to build with Mason? So for Linux, as I said, you can compile it and it starts. What I had to do is that I had to take

all the data files from an existing build. I just installed my binaries over that. So that's roughly where it's at. So it's like the first 90% is done and then there's the second 90% and the third 90% and so on. Again, so just getting stuff running is not that much

because the polish is where things actually matter. And then there are some corners which have been cut, like there's no Java support at the moment. And it gets very interesting because some of the unit testing that they do on C++ code is written in Java for some reason. So you need to have that.

It's a big project. Just to remind everyone, it sounds like you are still working a full-time job while also trying to build this tool. Yes. It's a lot of work. Yes, but there's a saying in Finland which goes like the following.

Bachelors have time for hobbies. So there you go. Now it's the COVID-19, so I'm going to be stuck here inside four walls anyway. So we expect that 1.0 release within the next few weeks then. That's how I just heard. Yeah. A few days. Two months of self-quarantine. Get it done.

Yeah. No, don't go crazy. Just for the record, since we did just bring it up again, there is an outside with sunshine that you can go to without interacting with other humans. Yes. This is Finland. There's no sunshine. Ah, well, maybe in a couple of weeks there'll be some sun coming up in Finland.

Hopefully. We have our last sunny day before we get another bout of snow actually coming up tomorrow. But that's Colorado. Yeah. Okay. Well, is there anything else you want to go over before we let you go, Yussi? Okay. So if we go back a bit, and I was like, the question is

why, if CMake is the standard, why should people change that? I'm thinking about this. There's actually a word for this, because replacing an existing standard with a different one, it's called progress.

That's what it is. If we never do that, then we'll still live in caves. And all compilation would be done by carrying boxes of punch cards from one place to another. And this is how progress works, is that you have a standard, but then you replace it with something better, hopefully. I did have one question about that. You talked about some of the projects that are using Mison now, did most of them come from older build tools or custom build tools

like things like just makescripts or autoconf or did you have any projects that you're aware of that came from CMake and are now using Mason and are happier with it most of the projects that I know of have come from Autoconf and possibly handwritten make files. That's the bulk. But there are several projects that I know of that have come from CMake. And based on the comments that I've heard, they've been pretty happy with it.

That's good. Cool. Okay. Well, it was great having you on the show again today, UC. Yeah, it's my pleasure. See you in another 201 episodes or so. Yeah. All right. Episode 440. All right.

Enjoy. Thanks. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter.

You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. 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 was provided by podcastthemes.com.