 I'm late let's go so that's me. I'm working at Canonical packaging LibreOffice for Ubuntu and also I am 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 just have a look at what we thought we would do back then and how 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 open office conference in 2010 except that it didn't have this branding but and well that was the goal back then and for the most part I think we we achieved that but it might not look like that if you're building LibreOffice now but you have to think about how how open office 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 change 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 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 standard run of these modules because we run all the tests by default all the time or lots of them and so we got a lot faster and then we added a lot of tests that you can't disable so we are back as slow as we were before unless you know how to trick around that but I'm not gonna 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 and 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 to read actually what others are doing and again by 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 yeah you could have multiple ways to do that and everyone what would cause interesting different slightly different effects so again it was troublesome whoops same slide so this 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 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 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 comp 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 hickory 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 pretty good thing but it's it's hard to like manually tell your IDE where all the 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 the which is studio because that's kind of hard of lin 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 a haven't the normal cross platform build that we have 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 it was K develop because well seem to be easy to me and again as I said that was not not something that was initially planned it was like an afterthought so what it did was you did a make NP which prints out out all the build information and then it passed that and tried to build the IDE solution from that turns out that something as simple as make NP 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 are we're taking more time to pass actually the info then then 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 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 is failing and they need a full build to get there that's the kind of sex so I now reorganized that and did all the the tricky stuff in the build system itself and then it just dumps that in Jason 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 young is young here nope young asked me well I looked at the files and and the compiler switches whoops the wrong slide that actually are given to to compile a C++ file on windows and almost all the stuff all the method 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 are the same for for the whole build but maybe we should I should just drop in JSON file next to it which which contains all this info so that you can actually from the JSON file find out all the flex that were used to build this on your specific platform so which ID ease do we have well K develop that was me in the beginning then Hansard did Visual Studio and young and others did additions to that Xcode was I think initially done by Tor and then a lot of work by young so we have like the major platform and major ID ease for each platform being able to to work on LibreOffice code in the native natively feeling environment and we have Vim and you completely by Moggy for the old Unix guys who wouldn't use anything new 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 we should we should get in contact with them and get your creator to be nicely integrated with that so the past was what what I aim to do with the original new build system eight years ago and this ID ease 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 maybe you are not entirely well neutral in on this so when I when I said well you should never look at this and 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 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 in to using something completely different these were the original problems we tried to solve with with eight years ago when we did this some of the stuff creep back in I think cargo code programming is already in the make files 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 that I spoke about do not repeat yourself and don't do Tim tov TDI and that's one of the main arguments against something like let's let's use visual studio directly 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 that unless you find a way to synchronize all this is really tricky the other challenges so I think we we should stay with with something that is one single build system whatever that is and well the the other stuff like having auto-generated intermediates who here uses automake and auto conf and loves it you're loving it okay we gotta talk the other stuff is well custom targets like again this is having more custom stuff in in the build targets which is not like the usual cross-platform stuff and the degrees of freedom in oh great later uh-huh 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 we that's a goal again to to get away from the build system and that means for example well the the candidates for this are obviously CMake or maybe use use scheme in in make as a migration path but the the advantage there is not to rewrite everything from scratch again but to softly migrate to it but the 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 yeah yeah yeah I'm mostly agree but I'm I mean I want to fight against my inner inner feeling that everything is fine so yeah but if I 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 other yes so the externals are actually yeah yeah interesting all right yeah anyone else but Norbert having questions yes well this it it there is somewhere deep inside is something that is generally usable but you 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 Miklosh once did an experiment to just get the build system out of LibreOffice and then try to to get rid of all the LibreOffice specific stuff so it was just one huge build system that built hello world but yeah also there are lots of optimizations that you 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 that doesn't work for LibreOffice so we are taking all these dependency files and pre-passing 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 right so you 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 to take a look at it looking forward for contributions 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 yeah right the partial build meaning that you touched one file and says it would do an incremental building 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 most of the time okay I think I'm over time already yes thank you