 All right. I'm late. Let's go. So that's me. I'm working at Canonical Packaging LibreOffice for Ubuntu and also I'm in the board of directors for the Document Foundation. And well, let's go back to 2010 because that was when the whole thing started with a new build system, new back then. And I wanted to just have a look at what we thought we would do back then and how we thought we could improve stuff back then and what we actually achieved from that. So yeah, that was one of the original slides from the OpenOffice conference in 2010 except that it didn't have this branding. And well, that was the goal back then. And for the most part, I think we achieved that. But it might not look like that if you're building LibreOffice now, but you have to think about how OpenOffice was building at that time. And there were many, many things that were broken there. There were manual dependencies. There were incomplete dependencies that were incompatible builds, which means that you could build one part and you had to know which part would change if you changed that. And if you didn't, horrible things would happen and all kinds of other issues. So those were the goals we had back then. Actually, I thought by now we would all use 32 core machines and that didn't happen. By now, we just use all very nifty laptops. But the other things still are true and are things that we very much profit from now. And if you use LibreOffice now and think, well, LibreOffice is still slow, that was the comparison from just building a few modules. That was back then and it's pretty much the same like that now, except that we almost take as much for standard run of these modules, because we run all the tests by default all the time, or lots of them. So we got a lot faster and then we added lots of tests that you can't disable so that we are back as slow as we were before, unless you know how to trick around that. I'm not going to tell you. So one other goal of this was to not repeat yourself. One other goal of this was to not repeat yourself, because repeating yourself is stupid. And especially if you're in the build system, you have multiple things that tell you how to build something that can again be inconsistencies and stuff that can create issues. For comparison, this is how it is in LibreOffice right now. You register if you want to have a new library there. You put it somewhere which says in the registry repository mk, which essentially says where it should end up in the final build. And well, then you say how to build it, like I want to build these C++ files. In the old open office world, well, it was a bit different. So that was one of the issues we had with the old stuff. The other thing was TimTofTDI. So there's more than one way to do it. And well, that's always a bad thing because you have to know all of them to read actually what others are doing. And again, by now if you want to, for example, export a symbol in LibreOffice, you do something simple like this. You add something DLL public to the declaration. And then the symbol is exported in open office. You could have multiple ways to do that in every one what would cause interesting different, slightly different effects. So again, it was troublesome. Oops, same slide. So this was the initial implementation of the back then new build system. We had all these targets in one huge dependency tree. And that meant that we were aware of all the stuff that was happening in all the build. We didn't have like these horizon effects where you would do an incompatible build, which meant you build something and said, I'm pretty sure this is binary compatible with the rest and trust me. And it actually knew if it was binary compatible or not. And most of the stuff, so the core stuff of this is still like that today. A few things changed like the backwards compatibility is gone. We don't need like to deliver and copy stuff five times around. We needed to do that in the old open office build system to be compatible with the old build system. So thanks to all these guys who helped contributing to this. The important quote here is, I say we take over Nuke the entire site from orbit. It's the only way to be sure that was the last comment when we killed the last part of the old build system. So that needed to be in the commit message there. So with this, we had the whole build system on essentially on one build system and not like we had before two or rather three, like the old one, the new one, and the one that mixed everything between those, which was some ugly pearl hackery. And then I got bored and I wondered if I could do more than the stuff that I originally planned for the new build system. And one of the things was, well, actually syntax highlighting and using IDEs is a pretty good thing, but it's hard to like manually tell your IDE where all the include paths are and things like that. On the other hand, well, we can't just say use Visual Studio and then we build everything with Visual Studio because that's kind of hard on Linux and on other platforms. So using just an IDE as the main build system doesn't work. But what we could do is have the normal cross-platform build that we had before and export solutions to different IDEs so they could be using this to give you a syntax highlighting, debugging, and stuff like that. So the first idea was K-develop because, well, it seemed to be easy to me. And again, as I said, that was not something that was initially planned. It was like an afterthought. So what it did was you did a make-n-p which prints out all the build information and then it parsed that and tried to build the IDE solution from that. Turns out that something as simple as make-n-p isn't really stable over different versions of make. So the parser for this turned to be, it always added more stuff and I looked at this and this is not good. We're taking more time to parse actually the info than is actually in there. And the result was always flaky because people were using different versions of make and it was kind of tricky to use this in a reliable way. And the goal of this was to have people who were new to development to get it on an IDE. And well, if the first thing they do is failing and they need a full build to get there, that kind of sucks. So I now reorganized that and did all the tricky stuff in the build system itself and then it just dumps that in JSON so that a simple Python script can read that and translate that to whatever IDE you want to have. So this is the solution right now and I think it it mostly is reliable and we can look here, right, there was a question from, where's Jan? Is Jan here? Nope. Jan asked me, well, I looked at the files and the compiler switches, the wrong slide, that actually are given to compile a C++ file on Windows and almost all the stuff, all the data about what definitions and flags and stuff are to be used for this target or in the JSON file with a few exceptions and this is what he was asking about. And that's these few, a few things still missing. That is like generally config specific stuff like which flags to use for exceptions and stuff like that, which is not target specific. So when he wrote this email, should they have been in the JSON? I said, well, no, because they are configuration specific and they're the same for the whole build. But maybe we should, I should just drop a JSON file next to it, which contains all this info, so that you can actually from the JSON file find out all the flags that were used to build this on your specific platform. So which IDEs do we have? Well, KDevelop, that was me in the beginning. Then Honza did Visual Studio and Jan and others did additions to that. Xcode was, I think, initially done by Tor and then a lot of work by Jan. So we have like the major platform, major IDEs for each platform being able to work on LibreOffice code in the natively feeling environment. And we have Vim and you completely by Moggy for the old Unix guys who wouldn't use anything newer. And, well, we have Qt Creator and actually one of the Qt Creator guys came up to me, he can't attend this talk, but he said, well, I really want to help out. So we should get contacted with them and get Qt Creator to be nicely integrated with that. So the past was what I aimed to do with the original new build system eight years ago. And this IDEs stuff is just like a nice additional feature. And there were like the ideas to maybe after eight years we should again use a new build system just cause. And, well, I felt like the old Unix guy that said, no, not with me. But there's this thing if you work too long on something that maybe you're not entirely well, neutral on this. So when I said, well, you should never look at this. I looked the next thing I did was look actually how much of this build system was actually done by me. And hey, good news. Although I brought the original stuff, there are other guys who do own a lot more lines of it by now than me. So it's not mine anymore. Great. David, Michael, congratulations. You own this thing now. So again, and also the distribution of country. So this is the lines of code and who last touched them. And it's pretty even distributed and there are a lot of people touching lots of areas there. So looking forward to using something completely different. These were the original problems we tried to solve with eight years ago when we did this. Some of the stuff creeped back in. I think cargo called programming is already in the makefiles is again on the rise because, well, it's been eight years and stuff collected in there. But in general, the other stuff is mostly reached. And I would add one more thing, the two that I spoke about. Do not repeat yourself and don't do TimTofTDI. And that's one of the main arguments against something like, let's use Visual Studio directly and then like export that to somewhere else. There's more than one way to do it. So again, I'm kind of reluctant to use something like Visual Studio Solutions directly and then have to maintain different build systems on all platforms because that will always break. And there's more than one truth to the build. So someone does something on Windows and then he changed the solution files but not the stuff for the other platforms and stuff like that. So that unless you find a way to synchronize all this, is really tricky. The other challenges, so I think we should stay with something that is one single build system, whatever that is. And, well, the other stuff like having auto-generated intermediates who here uses auto make and auto conf and loves it. You're loving it? Okay. Okay. We gotta talk. The other stuff is, well, custom targets like again, this is having more custom stuff in the build targets, which is not like the usual cross-platform stuff and the degrees of freedom in... Oh, great. Later. Basically, you can build a thing by just random computing. And the last number is, I run that once a day at night just for fun. And 79 failure, 11 success so far. Right. So we have way too much degrees of freedom in the configuration, especially on Windows where there should be pretty much only one mostly. And so that's a goal again to get away from the build system. And that means, for example, well, the candidates for this are obviously CMake or maybe use Scheme in Make as a migration path. But the advantage there is not to rewrite everything from scratch again, but to softly migrate to it. But the most interesting issue probably is the build execution because Ninja is a lot faster than what we have now because Make is just awfully slow parsing all the dependency files that we have, which are just huge. So, yeah? Yes, when you do a low build, the speed of Make is important. But when you build, build them all the time, what really matters today is not so much the build time is the reminding problem with parsing we do. We do have external that still run with minus J1 because they're still open and still can build power. And we have a lot of tests and some of them are really not balanced and they have a low payout. We spend quite a lot of time where we have only one part of the 32 that we hope we have and we think we have. We don't really use them. So right now there is probably 30% of perhaps time that couldn't be gained just by having the things back. I mostly agree. But I mean, I want to fight against my inner feeling that everything is fine. Make's goal is 32nd and it melts in my 15 seconds. But if I look at all these if I look at all these things, probably Ninja is the first most useful things of trying to attack within these rather than the others. So the externals are actually, yeah, interesting. All right. Anyone else but Norbert having questions? Yes? Well, there is somewhere deep inside is something that is generally usable, but you will have trouble finding it if you're not knowing about LibreOffice because there are these things like these multiple layers of where to put libraries and stuff that we are actually not using that much anymore, but they are still in there. I think Miklos once did an experiment to just get the build system out of LibreOffice and then try to get rid of all the LibreOffice specific stuff. So it was just one huge build system that built Hello World. Yeah. Also there are lots of optimizations that you probably only need if you're as big as LibreOffice like pre-compiled headers and windows having all this parallelization and Right. So stuff like that and having, for example, GCC creates the dependency files. Those are huge. They're too huge to be just, well, normally you would just use all of them, pass all of them and be fine. Well, that doesn't work for LibreOffice. So we are taking all these dependency files and pre-pausing them and kicking out all the stuff that is actually superficial and stuff like that. So if your project doesn't need 20 minutes on a 32-core machine, most people don't have a 32-core machine and so the build still takes 20 minutes. Right. So you're absolutely invited to look into the stuff and it's luckily not only me who knows about how this stuff works, which is good. And well, few, three, two, two, two, take a look at it. Looking forward for contributions. If the build takes 20 minutes on a one-core and that's all you have, one-core 20 minutes, this is not going to help you because all it did was simplify, how to run and parallelize it. We did a great progress in that. But it's really helping when you have actually so they go to feed. The rest of it is not really speed. Yeah. So again, in the comparison to the old build system, the most important thing was not even the speed. That was also important. But more important was getting rid of all the craft that was in the old stuff that collected over 20 years. The speed we got out of that is that all of a sudden we could do the partial build. Yeah. That worked. Right. The partial build meaning that you touched one file and says it would do an incremental build and actually would work because that didn't work in the old open office build system. You would touch one file and everything would be broken most of the time. Okay. I think I'm over time already. Yes. Thank you.