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.840 --> 06:23.840
unusual for cross-compilation, but we found it was pretty cool to add and to just prove

06:23.840 --> 06:27.880
that there really is no C's route.

06:27.880 --> 06:37.840
What happens next is a 100% aromatic link where absolutely everything has been cross-compile

06:37.840 --> 06:38.840
from source.

06:38.840 --> 06:46.320
So, all of the runtime is including the CRTs, and that's indian, allows us to

06:46.320 --> 06:53.440
to build a user program, fully air-metically compiled

06:53.440 --> 06:59.000
and linked for any target that we can support.

06:59.000 --> 07:04.400
So yeah, any host, any target, as long as we can build,

07:04.400 --> 07:07.960
as long as the target is supported by LLVM,

07:07.960 --> 07:10.000
and we have the build sources for that,

07:10.000 --> 07:12.520
then we can target absolutely everything.

07:12.520 --> 07:19.320
So far, we support these whole matrix and it's growing

07:19.320 --> 07:21.600
and it's getting easier and easier for us

07:21.600 --> 07:26.200
because the big work was at the beginning

07:26.200 --> 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.760
and we can support more targets.

07:35.760 --> 07:40.760
Yeah, the problem is we need to write the build files

07:40.760 --> 07:44.280
that's kind of the hard part there

07:44.280 --> 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 auditing on how all of those runtime

07:54.480 --> 07:58.520
is built, how to do it properly.

07:58.520 --> 08:02.120
In the special case of the GDBC, we go we offer

08:02.120 --> 08:04.600
every single version up to a cutting point

08:04.600 --> 08:09.400
that is the oldest LTS of RATGL,

08:09.400 --> 08:14.320
which we start with 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.920
because it is very, very hard to compile.

08:26.920 --> 08:31.920
It's quite hard to understand, yeah, I need to go fast, sorry.

08:31.920 --> 08:36.400
It's very hard, lots of McFiles cross-compiler.

08:36.400 --> 08:39.360
So we decided, OK, we're going to generate a stub library.

08:39.800 --> 08:44.040
We're all of the version symbols and then links against it.

08:44.040 --> 08:49.200
So we generate basically a stub assembly file

08:49.200 --> 08:53.440
with all of the versions per version of the GDBC.

08:53.440 --> 08:56.400
We compile it and we link against it.

08:56.400 --> 08:58.960
All of the symbols are null, but that's fully all right

08:58.960 --> 09:00.400
for all the satisfied linker.

09:00.400 --> 09:04.840
We actually took this from ZIG, if you want to check out,

09:04.880 --> 09:11.480
it's a very cool tool called ABI list tool,

09:11.480 --> 09:15.960
which we have in your best disk project for the GDBC.

09:15.960 --> 09:22.080
Quick demo before I give the mic to David.

09:22.080 --> 09:24.400
Where is he working?

09:24.400 --> 09:28.400
So here, we're going to cross-compile for Linux from Mac,

09:28.400 --> 09:32.480
Open SSL, and so it builds absolutely everything

09:32.480 --> 09:36.280
as we mentioned, all of the runtime is all of the compiler RT.

09:36.280 --> 09:38.960
It's a craft custom resource, dear.

09:38.960 --> 09:43.440
It crafts basically everything to hand over to the plan driver

09:43.440 --> 09:50.640
with do not pass any kind of additional flags to it.

09:50.640 --> 09:57.840
As you can see, it's dynamically linked Linux RTC4.

09:57.840 --> 10:00.120
And if you run it, Linux is just basically

10:00.120 --> 10:04.200
Docker to be able to run from Mac and it works.

10:15.560 --> 10:17.680
All right, so let's talk about some of the other components

10:17.680 --> 10:19.480
that we built.

10:19.480 --> 10:21.520
We added support for sanitizers.

10:21.520 --> 10:25.040
They're built from source as part of the build graph.

10:25.040 --> 10:26.240
So that's cool.

10:26.240 --> 10:29.760
If you pass dash dash config equals UBCAN,

10:29.760 --> 10:32.000
your binary gets built with UBCAN across all the platforms

10:32.000 --> 10:33.200
we support.

10:33.200 --> 10:36.240
We can link it statically dynamically, whatever.

10:36.240 --> 10:38.600
But cool other cool thing is, because the tool

10:38.600 --> 10:42.720
changed part of the build, we can rebuild LVM with UBCAN,

10:42.720 --> 10:44.680
and then build your binary with that.

10:44.680 --> 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.720
We build main works, which is like this extension library,

11:10.720 --> 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.000
And then there's a bunch of like MRI recipes

11:18.000 --> 11:20.640
for assembling these things into the way

11:20.640 --> 11:27.000
that the normal MNGW assist route layout looks like.

11:27.000 --> 11:29.720
So we replicate all of that and do it on the fly,

11:29.720 --> 11:33.720
and prepare all that for the linker to do the final link.

11:33.720 --> 11:35.560
So demo.

11:35.560 --> 11:36.760
That's so cool.

11:36.760 --> 11:37.280
Is that everyone?

11:37.280 --> 11:38.280
Yeah, it up.

11:38.280 --> 11:39.000
Yeah, cool.

11:43.000 --> 11:45.080
So here, we're going to change the platform slide

11:45.080 --> 11:50.200
to target 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 in the 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.840
We're going to run it on the line, and it's

12:12.840 --> 12:13.680
a little world.

12:13.680 --> 12:15.480
That's kind of neat.

12:15.480 --> 12:15.880
That better.

12:20.600 --> 12:21.040
Cool.

12:21.040 --> 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.200
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:17.160
a lot, 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 but we're most.

13:42.400 --> 13:44.200
Oh, yes, this is remote build of a thing we should

13:44.200 --> 13:47.200
produce, see with open SSL.

13:47.200 --> 13:52.840
So it's going to load, it's going to build, it's done building.

13:52.840 --> 13:54.960
That's kind of nice.

13:54.960 --> 14:00.200
And then build buddy has a nice UI for like visualizing the graph.

14:00.200 --> 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.960
So once you have this like hermatic cross tool chain,

14:11.960 --> 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, dash, config, it was bootstrapping.

14:21.760 --> 14:23.200
Then what a single build command.

14:23.200 --> 14:25.320
We're going to build you a fresh compiler,

14:25.320 --> 14:29.800
and then use that compiler 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 bootstrapping, bootstrap flag.

14:46.320 --> 14:49.040
And we're going to build LVM from source.

14:49.040 --> 14:52.960
And I'm going to build OpenSSL using the new LVM from source.

14:52.960 --> 14:54.640
This is all running remotely, because otherwise,

14:54.640 --> 14:57.680
it's going to take like 20 minutes or whatever, right?

14:57.680 --> 14:59.440
But if you throw it off, of course, at it,

14:59.440 --> 15:00.960
it's actually kind of pretty fast.

15:00.960 --> 15:05.560
Can see the 7,000 actions, which I have 7,000 files to combine.

15:05.560 --> 15:06.800
So that LVM's done.

15:06.800 --> 15:07.920
Now we're building up in a social.

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 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.560
We build with LTO and everything,

15:33.560 --> 15:37.880
but we 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 the 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 --> 16:00.040
It's going to take a while, but it's OK.

16:04.040 --> 16:05.720
What I also want to do, we are not support

16:05.720 --> 16:09.120
for more targets, more run times.

16:09.120 --> 16:13.560
If you have other ones, send us patches, come talk to us.

16:13.560 --> 16:15.200
We kind of want to be like complete and serve

16:15.200 --> 16:16.760
a variety of use cases.

16:16.760 --> 16:19.240
We already have some folks who submitted some stuff

16:19.240 --> 16:19.840
for Windows.

16:23.240 --> 16:25.440
We're looking at trying to get Cosmo LVM

16:25.440 --> 16:26.320
to see 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.800
that works across various platforms,

16:31.800 --> 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.200
if it's the same exact binary.

16:42.200 --> 16:44.240
So this little bit of a science project for now,

16:44.240 --> 16:47.720
but making some progress on it.

16:47.720 --> 16:48.760
And the final thing that we think

16:48.760 --> 16:52.160
would be really neat is to be able to eject from basil

16:52.160 --> 16:54.920
and kind of use 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.320
So we're not quite sure how this would look yet.

17:00.320 --> 17:03.240
It might be like this, where you actually create the cross

17:03.240 --> 17:08.240
end, and then use that, or it might be like a make cc approach,

17:08.240 --> 17:10.640
which we'll have like a shell script that uses basil

17:10.640 --> 17:14.760
under the hood to create it, and then run the filter to the build.

17:14.760 --> 17:17.680
We're going to play with it, see what feels good, see what works well.

17:17.680 --> 17:20.480
But yeah, definitely trying to bring the power

17:20.480 --> 17:23.160
basil to non-basely uses as well if possible.

17:26.640 --> 17:27.480
Cool.

17:27.480 --> 17:28.840
As all we have, thanks for listening.

17:28.840 --> 17:31.840
Here's our repo, everything's up there.

17:31.840 --> 17:33.160
And yeah, any questions?

17:33.160 --> 17:34.160
Yeah.

17:34.160 --> 17:44.800
Yeah, thanks for the architects.

17:44.800 --> 17:46.000
It's very exciting.

17:46.000 --> 17:49.840
I actually did something similar, so this time here.

17:49.840 --> 17:55.200
But my size is to work with Jesus, and therefore I cannot set it

17:55.200 --> 17:56.800
in English.

17:56.800 --> 17:59.920
But how I understood what basically you make

18:00.000 --> 18:02.280
sederanostasis or rapid electro bloodstains

18:02.280 --> 18:06.420
is like an organ Orchestra with Find so

18:06.420 --> 18:18.480
that you'll just make a GF C and use the

18:18.480 --> 18:21.840
Korean Devil so we will be kind of having a feito

18:21.840 --> 18:25.580
idea and something so.

18:25.580 --> 18:28.140
They're really can speaking visolo's over which is see.

18:28.140 --> 18:28.340
A part from March, and you'll actually will be

18:28.340 --> 18:30.900
G-lip-C, the water is going to be made to work or G-C-C.

18:30.900 --> 18:33.940
So I think we like simplify it a little bit.

18:33.940 --> 18:36.980
We don't build G-lip-C itself from source.

18:36.980 --> 18:41.180
We kind of build the headers in like an interface library.

18:41.180 --> 18:42.540
And then when we dynamically link,

18:42.540 --> 18:45.580
we end up using the system G-lip-C at one time.

18:45.580 --> 18:49.020
If that makes sense.

18:49.020 --> 18:51.820
But I don't know if you want to say more about that.

18:51.820 --> 18:54.500
Yeah, and for G-C-C, as you mentioned,

18:55.340 --> 18:59.380
so far, I don't think I have the energy to try to

18:59.380 --> 19:01.140
specify G-C-C.

19:01.140 --> 19:05.380
We have plenty to actually specify LB-C-C++

19:05.380 --> 19:07.900
and the bunch of other new projects.

19:07.900 --> 19:11.780
But G-C-C itself is just out of RAM, really.

19:11.780 --> 19:12.540
Let's start.

19:12.540 --> 19:12.980
OK.

19:15.980 --> 19:19.580
Let's imagine you have a way to run a possible binary.

19:19.580 --> 19:21.420
And then, could you rearrange the fields,

19:21.420 --> 19:25.220
the whole thing, and specializing, or what rule?

19:25.220 --> 19:27.100
Maybe you're already doing that?

19:27.100 --> 19:29.460
Yeah, the question is, can you run the cross-compiled binary

19:29.460 --> 19:31.900
to gather PGF statistics in like recompile?

19:31.900 --> 19:34.140
Yeah, so Bazel already has support

19:34.140 --> 19:39.980
for running a compilation with like a pre-uptained workflow.

19:39.980 --> 19:41.660
And you can kind of do it out of the box.

19:41.660 --> 19:43.060
It would be two separate build commands.

19:43.060 --> 19:44.860
Like, you would build a gathered profile

19:44.860 --> 19:45.860
than build again.

19:45.860 --> 19:49.380
We only get to cheat because our workload is compilation.

19:49.380 --> 19:51.540
So we can make it a very fancy build graph.

19:51.540 --> 19:53.540
But that's also kind of us, like, showing off.

19:53.540 --> 19:56.060
But I do think, like, they go the same approach.

19:56.060 --> 20:00.020
You could, if you encoded your like profile gathering

20:00.020 --> 20:02.260
thing as a build action, like it could also be wired

20:02.260 --> 20:03.180
together in similar way.

20:06.260 --> 20:07.060
Got it?

20:07.060 --> 20:09.860
Do you plan to have many, many packages to do?

20:09.860 --> 20:11.860
Do you make your show real best, Zella?

20:11.860 --> 20:14.700
Let's say that I won't use this for a complex project,

20:14.700 --> 20:17.540
but you want to kind of have that kind of basically

20:18.500 --> 20:21.660
Yeah, the question is do we intend to become a package manager?

20:21.660 --> 20:25.220
The answer is no, because Bazel has something called

20:25.220 --> 20:28.420
Bable Center Registry, which is repository of build rules

20:28.420 --> 20:31.660
for a bunch of packages.

20:31.660 --> 20:34.500
Not everything, but there's a fair amount growing like day by day.

20:34.500 --> 20:37.220
So the idea is, this is a tool chain that you bring into your project

20:37.220 --> 20:39.300
with like three lines of config.

20:39.300 --> 20:41.620
And then you can bring in all of those packages,

20:41.620 --> 20:43.940
as well, through the Bazel module system,

20:43.940 --> 20:45.540
and then basically compose those.

20:45.580 --> 20:50.780
So as long as they have build rules that build the thing

20:50.780 --> 20:53.780
and don't, some things only compile in certain platforms,

20:53.780 --> 20:55.380
but as long as they haven't really done that,

20:55.380 --> 20:58.780
we'll provide all the run times and all the standard library

20:58.780 --> 21:01.220
and everything, so you can kind of combine them.

21:01.220 --> 21:03.580
And this does work off the shelf for most things we tried.

21:08.100 --> 21:08.940
Yeah, good.

21:15.540 --> 21:27.740
So the question was, how do we deal with, if we need to depend on

21:27.740 --> 21:31.140
an SO library, like, pre-built SO library?

21:31.140 --> 21:36.260
So actually, Bazel already provides such a feature

21:36.260 --> 21:37.860
called CC in port.

21:37.860 --> 21:40.420
And for us, it's going to be armetic,

21:40.420 --> 21:44.460
because you reference the file as far as Bazel knows.

21:44.460 --> 21:47.380
It will know about that file.

21:47.380 --> 21:49.500
It will come into the links and box and then Nicky.

21:49.500 --> 21:50.700
So it just works.

21:50.700 --> 21:52.020
And we actually do that a lot.

21:54.860 --> 21:57.580
The file should exist on the platform, or yes.

21:57.580 --> 22:01.980
If not, I mean, I do that on another project.

22:01.980 --> 22:05.540
We just take them out of the wherever they are,

22:05.540 --> 22:08.700
and we just CC in port in Bazel, in Bazel.

22:09.700 --> 22:13.100
Yeah, Bazel also has really good support for bringing in remote files.

22:13.100 --> 22:15.460
You're going to address files by URL and hash.

22:15.460 --> 22:18.020
So you don't have to go and download things yourself.

22:18.020 --> 22:20.420
You can just say, hey, I depend on this file.

22:20.420 --> 22:22.540
That's hosted wherever.

22:22.540 --> 22:25.300
And then, you know, write a rule, bring that into your build,

22:25.300 --> 22:26.860
the SCC import.

22:26.860 --> 22:28.540
So that way, like, if I build a project this way,

22:28.540 --> 22:31.220
and then you go to load my repo, you don't have to go to download

22:31.220 --> 22:32.340
stuff, you can just run the build.

22:38.780 --> 22:40.100
Come, combine this outside after?

22:43.100 --> 22:46.020
APPLAUSE