WEBVTT 00:00.000 --> 00:12.400 Yeah, so there we want to present a good project of us, where we try to kind of revamp 00:12.400 --> 00:18.120 the way we do a cross-compilation using basal and LLVM. 00:18.120 --> 00:26.120 So you all know a cross-compilation is quite hard topic, it's quite arcane, mysterious, you 00:26.200 --> 00:32.440 have to master a lot of pieces to get it right, and it gets harder and harder the more platform 00:32.440 --> 00:34.240 you have, you add. 00:34.240 --> 00:44.000 So you know, you know, existing solutions are mostly sisterhood based, which you know are 00:44.000 --> 00:50.560 great, one stop shop, but also sometimes kind of a black box, you just trust what's 00:50.560 --> 00:51.560 in there. 00:51.560 --> 01:00.400 If you want to configure things differently, you can have projects like that, they are really 01:00.400 --> 01:12.400 great of the shelf solution, will cross-compile for any targets and do it quite well, 01:12.400 --> 01:14.400 using these routes, using pre-bilt. 01:14.400 --> 01:21.280 So all of these tools exist, which was a lot, you know, way beyond the scope of this project 01:21.280 --> 01:31.360 that is not just cross-compiling user programs, but entire Linux built, or as we so a couple 01:31.360 --> 01:41.880 presentations before stuff that also do from source, entirely from source, but very specific 01:41.880 --> 01:46.440 to one specific target. 01:46.440 --> 01:53.240 Then you have stuff like XXCC, which actually this project is heavy based on, as in, 01:53.240 --> 02:01.440 we don't use XCC, but we use a lot of the pre-sept in that, they do everything from source, 02:01.440 --> 02:04.560 and that's what we wanted to achieve with this project. 02:05.120 --> 02:10.880 Then you have stuff like Nix, which I'm not going to talk so much about, but it's cross-compilation 02:10.880 --> 02:16.680 is very well supported, but it is, makes a lot of assumption about where it's going 02:16.680 --> 02:24.360 to run, so it's also a great solution, just not what we're going to talk about. 02:24.360 --> 02:31.000 So what we want to do here is just cross-compile absolutely everything from source, because 02:31.080 --> 02:35.400 if you can cross-compile a very simple source, it means that using clung, which is a cross-compiler, 02:35.400 --> 02:44.000 we can target any of the platforms that LLVM supports, and essentially, allows us to 02:44.000 --> 02:51.240 cross-compile to any possible target within the realm of LLVM supports. 02:51.240 --> 02:58.240 So what we need for that, LLVM pre-built whole chain, source code for LVM, and all of 02:58.240 --> 03:05.040 the other one times, like G-lipsy, LLVM, which is a muscle, any kind of other one times, 03:05.040 --> 03:10.920 or esoteric, one times that you can think of, we need the source, and of course, we need 03:10.920 --> 03:18.320 basal, because that's what the talk is about, basal for dos, who not familiar, it's a 03:18.320 --> 03:26.320 build system, open source, build by Google, and one of the philosophy is that it drives you 03:26.320 --> 03:30.760 to declare absolutely everything as an input. 03:30.760 --> 03:36.800 So absolutely everything is an input, on variable, on variable, on input, tools, on input, 03:36.800 --> 03:45.520 every single header, and source, file is an input, and it allows us to do a much more 03:45.520 --> 03:48.840 correct build. 03:48.840 --> 04:03.300 So we use our own pre-built LLVM tool chain, with a slight twist, is that we use the very 04:03.300 --> 04:10.600 very cool tool from the LLVM project, the David Hunt, the other day, called the LLVM 04:10.600 --> 04:19.560 driver, that basically allows you to use lots of the LLVM tools, but as a single binary, 04:19.560 --> 04:27.160 pretty much like the Busy Box works, and this is interesting for us, because it allows 04:27.160 --> 04:37.200 us to ship a very, very minimal, a very, very small tool chains, with all of the 04:37.200 --> 04:48.700 clang, LLD, what else, object, object, object, object properties, and yeah, sort of 04:48.700 --> 04:53.920 megabytes, and that's pretty much all we need, plus, during time sources. 04:53.920 --> 05:00.760 So once we have all of that, and all honorable mention for David Hunt, for upstreaming a lot of 05:00.760 --> 05:07.960 things to LLVM, to make that possible, and to support a lot of tools that were not 05:07.960 --> 05:10.600 supported before. 05:10.600 --> 05:20.640 So with all of that, what we have is this kind of complex graph, not the complex one, 05:20.640 --> 05:27.200 when you know it, but basically the tool chain that we build is a multi-stage one, because 05:27.240 --> 05:33.320 the LLVM cannot depend on the LLVM, so we have to build the LLVM, or the parts of the 05:33.320 --> 05:42.640 LLVM, a very specific way, LLVM winds, same LLVM plus plus, same, all different stages, 05:42.640 --> 05:52.640 all different kind of dependencies, and at the end, we have a final, a complete tool chain 05:52.680 --> 06:00.400 that has all of the runtime dependencies that the normal program requires, and all of that 06:00.400 --> 06:03.760 built from source. 06:03.760 --> 06:11.760 The cool part is that, because everything is, is from source, and everything has been, 06:11.760 --> 06:16.360 like, download it, everything is aromatic, we can actually pass this flag, which is kind of 06:16.520 --> 06:23.640 unusual for cross-compilation, but we, we find it was pretty cool to add and to just prove 06:23.640 --> 06:27.600 that there really is no C3D. 06:27.600 --> 06:38.080 What happens next is 100% aromatic link, we are absolutely everything has been cross-compalled 06:38.080 --> 06:42.760 from source of all of the runtime, including the Syrtis, 06:42.760 --> 06:49.760 and that Indian allows us to build a user program 06:49.760 --> 06:54.040 fully air-metically compiled and linked 06:54.040 --> 06:58.920 for any target that we can support. 06:58.920 --> 07:04.400 So any host, any target, as we can build, 07:04.400 --> 07:08.000 as long as the target is supported by LLVM, 07:08.000 --> 07:10.040 and we have the build sources for that, 07:10.040 --> 07:12.680 then we can target absolutely everything. 07:15.680 --> 07:19.320 So far, we support these whole matrix and it's growing, 07:19.320 --> 07:21.560 and it's getting easier and easier for us 07:21.560 --> 07:26.160 because the big work was at the beginning 07:26.160 --> 07:27.360 while you're in everything. 07:27.360 --> 07:30.760 Now, adding targets is mostly writing build files, 07:30.760 --> 07:32.800 and then adding that to the graph, 07:32.800 --> 07:35.560 and we can support more targets. 07:35.560 --> 07:40.800 Yeah, the problem is we need to write the build files 07:40.800 --> 07:44.320 that's kind of the hard part there 07:44.320 --> 07:48.480 between David and I, we implemented a lot of that. 07:48.480 --> 07:54.480 So it's a lot of editing on how all of those runtime 07:54.480 --> 07:58.560 is built, how to do it properly. 07:58.560 --> 08:02.200 In the special case of the GDBC, we go, we are far, 08:02.200 --> 08:04.600 every single version up to a cutting point 08:04.600 --> 08:09.320 that is the oldest LTS of RHDL, 08:09.320 --> 08:14.320 which we start with was a good minimal version to support. 08:14.320 --> 08:18.360 So we have to adapt the build files for the versions. 08:18.360 --> 08:22.960 The problem also with the GDBC is a kind of a specific case 08:22.960 --> 08:26.880 because it is very, very hard to compile. 08:26.880 --> 08:30.080 It's quite hard to understand. 08:30.080 --> 08:32.120 Yeah, I need to go fast, sorry. 08:33.040 --> 08:36.400 It's very hard, lots of McFiles cross-compiler. 08:36.400 --> 08:39.880 So we decided, OK, we're going to generate a stub library 08:39.880 --> 08:44.120 with all of the version symbols and then links against it. 08:44.120 --> 08:49.240 So we generate, basically, like a stub assembly file, 08:49.240 --> 08:53.480 with all of the versions per version of the GDBC. 08:53.480 --> 08:56.440 We compile it and we link against it. 08:56.440 --> 08:58.960 All of the symbols are null, but that's fully all right 08:58.960 --> 09:00.480 for all the satisfied linker. 09:00.480 --> 09:04.880 We actually took this from ZIG, if you want to check out, 09:04.880 --> 09:10.720 it's the very cool tool called ABL, ABL, ABL, 09:10.720 --> 09:13.840 I list all, which we have in our best disk project 09:13.840 --> 09:16.040 for the GDBC. 09:16.040 --> 09:22.040 Quick demo before I give the mic to David. 09:22.040 --> 09:23.040 Oh, is it working? 09:23.040 --> 09:24.560 OK. 09:24.560 --> 09:28.600 So here, we're going to cross-compile for the next front Mac 09:28.600 --> 09:30.280 of an SSL. 09:30.280 --> 09:33.480 And so it builds absolutely everything, as we mentioned, 09:33.480 --> 09:36.280 all of the runtime is all of the compiler-arty. 09:36.280 --> 09:39.000 It's a craft custom resource-dier. 09:39.000 --> 09:41.680 It crafts, basically, everything to hand over 09:41.680 --> 09:48.920 to the clung driver, we do not pass any kind of adi-chonol 09:48.920 --> 09:50.640 flags to it. 09:50.640 --> 09:57.880 As you can see, it's dynamically linked links are cheesy for. 09:57.880 --> 10:00.160 And if we run it, line is just basically 10:00.160 --> 10:04.200 Docker to be able to run from Mac and it works. 10:15.560 --> 10:17.640 All right, so let's talk about some of the other components 10:17.640 --> 10:19.480 that we built. 10:19.480 --> 10:21.520 We added support for sanitizers. 10:21.520 --> 10:25.080 They're built from source, that's part of the build graph. 10:25.080 --> 10:26.200 So that's kind of cool. 10:26.440 --> 10:29.840 If you pass, like dash dash config equals UBCAN, 10:29.840 --> 10:32.000 your binary gets built with UBCAN across all the platforms 10:32.000 --> 10:33.240 we support. 10:33.240 --> 10:36.280 We can link it statically dynamically, whatever. 10:36.280 --> 10:38.640 But cool, other cool thing is, because the tool 10:38.640 --> 10:42.760 changed part of the build, we can rebuild LVM with UBCAN 10:42.760 --> 10:44.720 and then build your binary with that. 10:44.720 --> 10:49.280 So if folks are working on debugging LVM or something, 10:49.280 --> 10:51.680 that's like a cool, fun, handy thing. 10:51.680 --> 10:55.200 So we support Windows. 10:58.480 --> 11:00.760 So Windows, we built from source. 11:00.760 --> 11:04.320 So we use the MNGW project, which is great. 11:04.320 --> 11:06.480 But we wrote build rules to build a CRT's. 11:06.480 --> 11:10.760 We build main works, which is like this extension library 11:10.760 --> 11:12.920 and a couple other like C libraries, which 11:12.920 --> 11:16.040 generate import lives from all the.dev files. 11:16.040 --> 11:18.040 And then there's a bunch of like MRI recipes 11:18.040 --> 11:20.680 for assembling these things into the way 11:20.680 --> 11:27.040 that the normal MNGW assist route layout looks like. 11:27.040 --> 11:30.120 So we replicate all of that and do it on the fly and prepare 11:30.120 --> 11:33.760 all that for the linker to do the final link. 11:33.760 --> 11:35.760 So demo. 11:35.760 --> 11:37.240 Is that everyone? 11:37.240 --> 11:38.040 You have it up? 11:38.040 --> 11:38.400 Yeah. 11:43.040 --> 11:45.520 So here, we're going to change the platform slide to target 11:45.520 --> 11:50.200 Windows AMB64, but we also support ARM64. 11:50.200 --> 11:53.200 And we're going to go ahead and build that from source as well. 11:53.200 --> 11:55.640 So right now, it's creating all the import libraries 11:55.640 --> 12:00.120 compiling with libc++, targeting Windows. 12:00.120 --> 12:02.560 And then it'll finish this sec. 12:02.560 --> 12:07.440 And we have a, oh, there we go. 12:07.440 --> 12:09.240 We have our Windows file. 12:09.240 --> 12:12.440 We're going to run it on the line. 12:12.440 --> 12:13.680 And it's a little world. 12:13.680 --> 12:15.440 That's kind of neat. 12:15.440 --> 12:15.940 That better. 12:20.600 --> 12:20.960 Cool. 12:20.960 --> 12:23.320 So why do we do all this other than the fact 12:23.320 --> 12:27.240 that we're nerds and we love doing crazy stuff like this? 12:27.240 --> 12:30.280 So this lets you do remote builds with zero setup, 12:30.280 --> 12:31.920 because everything is defined from source 12:31.920 --> 12:33.160 as part of your build graph. 12:33.160 --> 12:34.880 All of your build actions are able to be 12:34.880 --> 12:38.560 scheduled for remotely across a ton of cores. 12:38.560 --> 12:41.200 So we'll show a demo of that in a bit. 12:41.200 --> 12:44.760 This also means you get a working cross compilation 12:44.760 --> 12:47.400 for C and a cross linker for other languages. 12:47.400 --> 12:49.440 So you can plug this in as a linker for rust, 12:49.440 --> 12:52.840 for go, et cetera, for go requires a patch 12:52.840 --> 12:55.240 to go tool chain, what we submitted. 12:55.240 --> 12:57.080 But for rust, it kind of just works out in the box. 13:01.960 --> 13:04.320 Big shout out to our friends at build buddy. 13:04.320 --> 13:08.440 Build buddy is a remote execution provider for basal builds. 13:08.440 --> 13:11.400 We kind of abuse them a ton to run a bunch of these things, 13:11.400 --> 13:14.440 because as you can imagine, we are building LVM from source 13:14.440 --> 13:15.000 a lot. 13:15.000 --> 13:17.160 And it's not that fast to build, except for us. 13:17.160 --> 13:18.880 It's very fast to build. 13:18.880 --> 13:20.720 I don't know if you can see this, but it's just showing 13:20.720 --> 13:22.120 a profile of the graph. 13:22.120 --> 13:26.560 There's like 700, 800 cores working on this build. 13:26.560 --> 13:30.720 So if you just kind of sharded out, it's OK. 13:30.720 --> 13:31.800 Let's show them the sample of that. 13:38.720 --> 13:39.440 What is the example? 13:39.440 --> 13:41.080 What are we showing, Ashley? 13:41.080 --> 13:42.400 Same with the remote. 13:42.400 --> 13:44.200 Oh, yes, this is remote build of a thing we should 13:44.200 --> 13:47.160 produce, see with open SSL. 13:47.160 --> 13:52.840 So it's going to load, it's going to build, it's done building. 13:52.840 --> 13:54.920 That's kind of nice. 13:54.920 --> 14:00.160 And then build buddy has a nice UI for like visualizing the graph. 14:00.160 --> 14:01.000 That's the same thing. 14:04.360 --> 14:05.520 Cool. 14:05.520 --> 14:08.440 The final thing is bootstrapping. 14:08.440 --> 14:11.920 So once you have this like hermetic cross tool chain, 14:11.920 --> 14:13.640 you can build LVM itself, which 14:13.640 --> 14:17.080 is what we do as part of our release process. 14:17.080 --> 14:18.800 But we also integrated it into the build graph. 14:18.800 --> 14:21.760 So if you pass dash-configure was bootstrapped, 14:21.760 --> 14:23.280 then with a single build command, we're 14:23.280 --> 14:26.280 going to build you a fresh compiler, and then use that compiler 14:26.280 --> 14:29.800 to compile your user code. 14:29.800 --> 14:32.280 And it's basically the graph de-plicated, 14:32.280 --> 14:35.240 because that's a bootstrapping, because right? 14:35.240 --> 14:37.680 Yep, it's a single build. 14:37.680 --> 14:39.280 Cool, let's show a demo of that as well. 14:39.280 --> 14:46.320 So here we pass the extra bootstrapped, bootstrapped flag. 14:46.320 --> 14:49.040 And we're going to build LVM from source. 14:49.040 --> 14:52.920 And I'm going to build Open SSL using the new LVM from source. 14:52.920 --> 14:54.640 This is all running remotely, because otherwise, 14:54.640 --> 14:57.640 it's going to take like 20 minutes or whatever, right? 14:57.640 --> 14:59.400 But if you throw it off, of course, at it, 14:59.400 --> 15:00.960 it's actually kind of pretty fast. 15:00.960 --> 15:03.280 Can see the 7,000 actions, which I haven't 15:03.280 --> 15:05.520 7,000 files to combine. 15:05.520 --> 15:07.920 So that LVM's done, now we're building up in SSL. 15:10.080 --> 15:12.200 If you ever are developing LVM, again, 15:12.200 --> 15:15.080 you can make a change to LVM in your local checkout, 15:15.080 --> 15:16.440 and then iterate on the entire thing 15:16.440 --> 15:17.680 and then to end the single build command. 15:23.280 --> 15:24.080 Cool. 15:24.080 --> 15:27.160 OK, I don't know if we need that. 15:27.160 --> 15:27.880 Cool. 15:27.880 --> 15:29.880 So what's next? 15:29.880 --> 15:31.360 So right now, we build LVM. 15:31.360 --> 15:33.920 We build with LTO and everything, but we 15:33.920 --> 15:37.880 would love to instrument it and do FDU. 15:37.880 --> 15:41.600 So the best way to instrument a compiler is to compile some stuff. 15:41.600 --> 15:44.760 So our build graph will look like this. 15:44.760 --> 15:46.680 We're going to build LVM from source. 15:46.680 --> 15:49.040 We're going to use that new LVM to build an optimized 15:49.040 --> 15:50.280 and instrument to LVM. 15:50.280 --> 15:51.800 We're going to use that to compile LVM 15:51.800 --> 15:53.760 to get your profiling data. 15:53.760 --> 15:55.160 And then we're going to combine all of that 15:55.160 --> 15:58.000 into like a final optimized compiler. 15:58.000 --> 15:59.960 It's going to take a while, but it's OK. 16:03.960 --> 16:05.720 What I also want to do, we are not support 16:05.720 --> 16:09.160 for more targets, more run times. 16:09.160 --> 16:13.600 If you have other ones, send us patches, come talk to us. 16:13.600 --> 16:15.280 We kind of want to be like complete and serve 16:15.280 --> 16:16.800 a variety of use cases. 16:16.800 --> 16:19.280 We already have some folks who submitted some stuff 16:19.280 --> 16:19.880 for Windows. 16:23.280 --> 16:26.320 We're looking at trying to get Cosmo Lipsy working. 16:26.320 --> 16:29.640 We're going to be pretty neat to have a single compiler binary 16:29.640 --> 16:31.840 that works across various platforms, 16:31.840 --> 16:34.040 because especially with like remote execution, 16:34.040 --> 16:37.520 you can share your action inputs and get cache hits, 16:37.520 --> 16:40.200 no matter which platform the actual compiler ran on 16:40.200 --> 16:42.280 if it's the same exact binary. 16:42.280 --> 16:44.280 So this is a little bit of a science project for now, 16:44.280 --> 16:47.760 but making some progress on it. 16:47.760 --> 16:49.920 And the final thing that we think will be really neat 16:49.920 --> 16:52.680 is to be able to eject from basil and kind of use 16:52.680 --> 16:54.920 basil to produce a normal cross compiler, 16:54.920 --> 16:58.240 or a normal sys route, and then use that to power other projects. 16:58.240 --> 17:00.360 So we're not quite sure how this would look yet. 17:00.360 --> 17:03.320 It might be like this, where you actually create the cross 17:03.320 --> 17:08.320 end, and then use that, or it might be like a make cc approach, 17:08.320 --> 17:10.320 which will have like a shell script that uses 17:10.320 --> 17:11.600 basil under the hood to create it, 17:11.600 --> 17:14.840 and then run the filter to the build. 17:14.840 --> 17:17.760 We're going to play with it, see what feels good, see what works well. 17:17.760 --> 17:20.560 But yeah, definitely trying to bring the power 17:20.560 --> 17:23.240 basil to non-basely uses as well if possible. 17:26.680 --> 17:27.560 Cool. 17:27.560 --> 17:28.880 As all we have, thanks for listening. 17:28.880 --> 17:31.880 Here's our repo, everything's up there. 17:31.880 --> 17:33.200 And yeah, any questions? 17:33.200 --> 17:34.200 Yeah. 17:34.200 --> 17:46.040 Yeah, thanks for the architects, it's very exciting. 17:46.040 --> 17:49.880 I actually did something similar, so this time here. 17:49.880 --> 17:54.320 But mine's the highest of work, which is, and therefore, 17:54.320 --> 17:59.400 I cannot set it in English, but how I understood what basically 17:59.400 --> 18:01.640 you may see when it's a delicious restaurant. 18:01.640 --> 18:06.160 The texture, basil, cc like a pork can be in place 18:06.160 --> 18:11.160 with the grass, so you will just make a gc, and then 18:11.160 --> 18:14.280 also become a kind of cool material, like the deal, 18:14.280 --> 18:16.680 by a server cc like that. 18:16.680 --> 18:19.240 So they're really good to be speaking visculose over 18:19.240 --> 18:23.040 which is cc, apart from the part where you are actually 18:23.040 --> 18:25.760 building people, but I don't understand what cc is. 18:25.760 --> 18:28.840 Yeah, the question is, how we handle glip c 18:28.840 --> 18:30.920 and water is going to be made to work, or gcc? 18:30.920 --> 18:33.920 So I think we like simplify it a little bit. 18:33.920 --> 18:37.000 We don't build glip c itself from source. 18:37.000 --> 18:41.160 We kind of build the headers in an interface library, 18:41.160 --> 18:42.560 and then when we dynamically link, 18:42.560 --> 18:46.720 we end up using the system glip c at one time. 18:46.720 --> 18:50.160 If that makes sense. 18:50.160 --> 18:52.080 But I don't know if you want to say more about that. 18:52.080 --> 18:54.480 Yeah, and for all gcc, as you mentioned, 18:54.480 --> 18:56.600 do we so far? 18:56.600 --> 19:01.240 I don't think I have the energy to try to specify gcc. 19:01.240 --> 19:03.600 We have plenty to actually specify lb, 19:03.600 --> 19:07.000 is it a stdc plus plus, and the bunch of other 19:07.000 --> 19:07.960 new projects. 19:07.960 --> 19:11.760 But gcc itself is just out of RAM, really. 19:11.760 --> 19:12.560 Let's start. 19:12.560 --> 19:12.760 OK. 19:15.760 --> 19:16.280 Yeah. 19:16.280 --> 19:19.600 Let's imagine you have a way to run a possible by binary. 19:19.600 --> 19:22.240 And then could you rearrange the gls and all things, 19:22.240 --> 19:25.200 and specializing for the workload? 19:25.840 --> 19:29.040 Yeah, the question is, can you run the cross-compiled 19:29.040 --> 19:31.840 binary to gather pg of statistics and recovery compile? 19:31.840 --> 19:32.160 Yeah. 19:32.160 --> 19:36.440 So basal already has support for running a compilation 19:36.440 --> 19:40.000 with like a pre-uptained workflow. 19:40.000 --> 19:41.640 And you can kind of do it out of the box. 19:41.640 --> 19:43.040 It would be two separate build commands. 19:43.040 --> 19:44.840 Like you would build a gathered profile 19:44.840 --> 19:45.840 than build again. 19:45.840 --> 19:49.400 We only get to cheat because our workload is compilation. 19:49.400 --> 19:51.560 So we can make it a very fancy build graph. 19:51.560 --> 19:53.560 But that's also kind of us, like, showing off. 19:53.560 --> 19:56.080 But I do think, like, they go the same approach. 19:56.080 --> 20:00.040 You could, if you encoded your like profile gathering 20:00.040 --> 20:02.320 thing as a build action, like it could also be wired 20:02.320 --> 20:03.120 together in similar way. 20:06.280 --> 20:07.120 Got it? 20:07.120 --> 20:09.880 Do you plan to have many, many packages to do? 20:09.880 --> 20:11.920 Do you make your show relevant to them? 20:11.920 --> 20:14.760 Let's say that I won't use them for a complex project, 20:14.760 --> 20:17.560 but do you want to account that kind of basically 20:17.560 --> 20:19.280 can work in the different way? 20:19.280 --> 20:21.720 Yeah, the question is, do we intend to become a package manager? 20:21.720 --> 20:25.160 The answer is no, because Basel has something called 20:25.160 --> 20:28.440 Badalcentra Registry, which is repository of build rules 20:28.440 --> 20:31.800 for a bunch of packages. 20:31.800 --> 20:34.600 Not everything, but there's a fair amount growing like day by day. 20:34.600 --> 20:36.840 So the idea is, this is a tool chain that you bring into your 20:36.840 --> 20:39.360 project with like three lines of config. 20:39.360 --> 20:42.440 And then you can bring in all of those packages, as well, 20:42.440 --> 20:45.600 through the Basel module system, and then basically compose those. 20:45.600 --> 20:50.800 So as long as they have build rules that build the thing 20:50.800 --> 20:53.760 and don't, some things only compile in certain platforms, 20:53.760 --> 20:55.360 but as long as they haven't really done that, 20:55.360 --> 20:58.720 we'll provide all the run times and all the standard library 20:58.720 --> 21:01.200 and everything so you can kind of combine them. 21:01.200 --> 21:03.560 And this does work off the shelf for most things we try to. 21:08.080 --> 21:09.080 Yeah, good. 21:09.080 --> 21:14.080 How could them work for things that I won't want to build? 21:14.080 --> 21:17.920 If I have to depend on some other, just to let me know 21:17.920 --> 21:31.200 if we need to depend on the S-O library, like Pribil, the S-O library. 21:31.200 --> 21:37.880 So actually, Basel already provides such a feature called CC Import. 21:37.880 --> 21:41.360 And for us, it's going to be armetic, because you refer 21:41.360 --> 21:47.360 us to the file as far as Basel knows, it will know about that file. 21:47.360 --> 21:49.520 It will come into the links and box and then Nicky. 21:49.520 --> 21:50.720 So it just works. 21:50.720 --> 21:53.000 And we actually do that a lot. 21:53.000 --> 21:57.600 The file should exist on the platform, or yes. 21:57.600 --> 22:02.000 If not, I mean, I do that on another project. 22:02.000 --> 22:05.600 We just take them out of the wherever they are, 22:05.600 --> 22:09.600 and we just CC Import in Basel. 22:09.600 --> 22:13.040 Yeah, Basel also has really good support for bringing in remote files. 22:13.040 --> 22:15.440 You're picking your trust files by URL and hash. 22:15.440 --> 22:18.000 So you don't have to go and download things yourself. 22:18.000 --> 22:20.400 You can just say, hey, I depend on this file. 22:20.400 --> 22:22.560 That's hosted wherever. 22:22.560 --> 22:25.280 And then, you know, write a rule, bring that into your build, 22:25.280 --> 22:26.840 the SCC Import. 22:26.840 --> 22:28.480 So that way, like, if I build a project this way, 22:28.480 --> 22:30.480 and then you go, close my repo. 22:30.480 --> 22:31.480 You don't have to go to download stuff. 22:31.480 --> 22:32.320 You can just run the build. 22:38.800 --> 22:40.000 Come upon Assassin, after? 22:40.000 --> 22:42.000 Thank you. 22:42.000 --> 22:44.000 Thank you. 22:44.000 --> 22:46.000 Thank you.