 So, I guess I can just start because it's time and for whether anybody else will start. So, yeah, my name's Yav, I work at Google on Yate, and I'm good to present for hanging note core to GN. So, we're going to talk about the favorite topic of everybody, which is build system. And I found this trick to really expressive for the approach that Noah has for the current build system issue. So, the issue with build system has been there for the past three years. Nothing has happened since then. And the reason nothing has happened is that because it's complicated. So, note, first thing first, JIP is a build system that no currently uses. GN is another build system that V8 currently uses. V8 used to use JIP, but we stopped doing that about three years ago. And about one half years ago, we stopped updating JIP corporations from V8. The problem here is that no actually still uses JIP, and one of the reasons no still uses JIP is that all native modules rely on JIP to build. And like I said, at some point, we continued the JIP build, but V8 actually tests against node in our continuous integration, which means we have to find a way to build V8 without updating our own JIP files because we stopped doing that, but still make sure that we can still build node. And another thing to this issue is that the GN team is not willing to throw in the scope of supporting anything else in CoralWheel. So, that makes it kind of not nice to switch over to GN. So, what we do at V8, or at least what we used to do at V8 is we have this thing called DashDirect Build V8 with GN, and what actually happens there is we would build V8 with GN into a cycle library, and we would build the rest of node with a different tool chain and different system, and then at the end, they would close it together. And it worked well for us for some time, but it breaks often, and when it breaks, I usually use the one who has to shuffle around, see how it works, and it got a little bit annoying. So, what I did was, at some point, I said, well, let's rethink this, and maybe we can find a better solution. Turns out that Electron actually already ported node to GN because Electron uses node as one of its dependencies, Electron uses Chrome, and Chrome uses GN, so Electron uses GN, and so Electron was forced to actually come up with GN files for node, and I was thinking, hey, maybe I can just take it, and it works for node. There was quite a bit of things missing, so what I learned through Intimate Nails is that GN is actually pretty nice compared to TIP, because TIP is just a huge, like, Python object usual that the TIP script knows how to parse. GN has actually the same syntax, and it's pretty nice. The problem here is that Electron's GN files are very incomplete. It doesn't have, like, a build target for nodes executable. There's nothing to do with the tests. It's not like you can just build it and it works on as a box. One of the issues is also the Electron version relies on boring SSL, because it's part of Chromium, but node actually uses something SSL, which has diverged in the last few years. While working on this, I also found that the Electron board for GN has a bunch of bugs in there. There were a bunch of things wrong, and actually to make node passable tests, you actually have to create this config GP file that's embedded into node itself, and a bunch of those tests rely on the content of the config GP. So I had to emulate the content of the config GP as well. So this is an excerpt out of the GN file that I wrote for node. So we have the build target for node lib. We have executable, we have actions to run, and build to snapshot, and from my perspective, they are fairly easy to create and a lot nicer than chip. So currently, this is a fork on the Chromium repo. Anybody is welcome to take a look. There are a couple numbers I want to share. So the whole thing is mostly just a couple of scripts, a couple of build.gn files, and gni that sends for GN-induced. All I know is about 4,000 lines of code. What I was able to achieve from this is that building nodes on our continuous integration got a lot faster. I used a dependency management system to pull in the dependencies. It works on Linux Mac. Windows not that much because I still haven't gotten native audios to work. One of the things that you can do now with the GN build is that there's this thing called jumble build, which makes building a lot faster. So you can actually build it on a macro pro within nine minutes. So I also want to talk about dependencies. So one of the changes I made is about managing dependencies for nodes. For everyone who already worked with Chromium or V8, know that if you want to set up to check out the directory, one of the things that you have to do is define string, which looks at the content of the test file, which then pulls all of those dependencies. And the next thing I found out is that you can just specify all your dependencies as sort of, yeah, just one line, like where it comes from, and which revision you want them, and not actually embed them directly into a repository like Chromium was going down for ICU or V8, or all other dependencies that don't exist. So this is an example of the test file. As you can see, those entity and node are just dependencies of this project. So the port itself is just a bunch of scripts and build files. It doesn't actually include the source code for V8, or Node, or ICU. They're just specified as the case where you get them and they can't. So if you want to generate V8 in this repository, the only thing you have to do is to change the commit ID, the commit hash, and then do a different sync. It would then automatically pull the right version of V8, and you don't have to care about the contents. So the result is that it's the greatest node build ever, partly. So it's easier to update V8, like I just said, because all you have to do is to change that file. It's also easier to sync with upstream node, because Node is just another dependency here as well. It makes it very easy for us to in V8 team to test against Node with changing the versions, because all you have to do, like I said, is to place the commit hash. One thing that you can have as a game build is sanitiser builds, like other sanitiser, thread sanitiser, undefined behavior sanitiser, and because there exists the configurations for the build for those sanitizers already in the GM. And also, Jungle Build is included. So maybe to slide back, Jungle Build is a way to speed up compiling a building by just merging individual smaller files into bigger ones, so that the compiler only has to compile one big file, which is a whole process of compiling every single individual file. So one caveat here is that I know that those are actually not supported, because they are specifying a strip, and I haven't spent the time to dig into how MPM is installed. That's all the magic of finding the tool chain, and what it does with them, and like combining the stuff from common GP and conflict to be in the entire tool chain. So this is strange enough. So for the future, I'm thinking maybe you can kind of string this as a secondary build system alongside JIT, just to make it easier to maintain. I'm not sure whether the dependency management system is something that nobody wants. Personally, I like it a lot because it makes things easier. It makes things like upgrading single components a lot easier. One of the questions is niche platforms like 3DSD, that not a lot of people support, to which GN is not supported. And one of the outstanding things in my current implementation is that there is not a good implementation for building a new proposal right now. I'm just doing the very basic version. It doesn't support like a generic assembly. So this is what happens if you try to build it. Is there any chance that the GM team will broaden their support plans and include note? So I just point there are none, but I am so talking to you. Because that would be a much better solution from my personal point of view. I guess it is a good solution for building a core, but not so much for no audience. Yeah, no, I agree. But for no core, it would be a much better, much, much better solution. So I am, if there is anything that we can do as note to make a case for it, I think we can possibly work on such a statement. Yeah, so I am definitely going to continue talking to the GM team, to lobby them into extending their support for non-communist individuals, maybe that would be awesome. Yeah, but you know, if you ask us asking the formal question or something, as the TSE or whatever, we can, you know, we can work on that. It's just that it seems to me, especially considering the electron use case, having a single build system for note core would be way, way more maintainable and the last, you know, wasting work cycles on things that should not, we should not waste work cycles on. So one of the things I am trying to get out of this forum here is like, whether it makes sense for us to have PN as a second-order for note. Like, not the default one, but at least have it as part of a note upstream repo so that, you know, it's easier to fix break it. I would recommend to file PR. Okay. So I maintain native modules. The blockers for native modules. Well, I guess, I mean, the way that no modules are expected to be built is using just, and there is, I don't think there is an easy upgrade pass here, because if you move the expectations of GM, then you have all of those existing modules that are still using it. We cannot interpret them. So I don't know. So at the individual module layout, like, there you have, of course, the store scripts, but that just takes off the GM process rather than the I don't have the MST for GIF stuff. I guess that would work, yeah. Okay. So last year when I checked and talked to people about doing a build of GM, it seemed like the major blocker, so I talked to the electron folks about this, because they were not really talking about the data side, but it seemed like the major blocker for switching over Node 4 would probably be Node WebKit, because of how its dependency structure thing works. Obviously, I mean, well, we don't need to worry about native modules as much, because the don't use the same build system, and they can keep using GIF at least for now. So I'm not sure if you have got an answer for anyone over there. I have no idea about Node WebKit as it is. Do you have any details and what the problem is? No, but if you asked Shelly for, she might know. Okay, so I got that. Yeah, I haven't gotten anything in that area so far. So last time I talked to her, she was happy that I'm doing it, but she didn't tell me anything about Node WebKit. I'm sure the electron team is not necessarily going to do this to them. Yeah, I also have turned a couple of fixes to them. So one of the things I'm still doing here, you can see here, is that building native modules, like there's a bunch of Allen tests in Node 4. They are still built using GIF, because all I'm doing there is to refer to the NGN scripts that took off the build for Node modules. And there's also one of the places that doesn't port hold NGN windows, because you just don't have to correct two things without the test test form points. And one nice thing about NGN is actually that a part of the dependency management, you also get the toolchain and toolchain configuration. This is dependencies, so you always know that it will build because it just brings its own toolchain. Of course, I mean, it's not built to have to download. And the toolchain configuration is part of building it. In that case, if nobody has any more questions. There's a question online. Okay. This is from Raphael. I hope someone sees this, but one of my goals for GIF3 is to be able to consume GN syntax. That sounds awesome. Because then we can just switch to GN syntax and we'll work with either GIF4 or GN. Sounds like a good hybrid solution. So that makes sense that I'll try to have the same with GN as a surprise. Maybe not with dependency management system, because I think that would be a large change to note. But it's just about the GN That's it. That's it.