WEBVTT 00:00.000 --> 00:10.200 Okay, so hello everyone, I'm Sergio Pasta Perez, and today I'm going to present a 00:10.200 --> 00:14.200 U-blue, a generic build system crafted entirely in guide. 00:14.200 --> 00:19.600 We've been developing this project over the past year, alongside my friend Oliver Tion, 00:19.600 --> 00:24.000 which is actually the skin wizard behind any of the features I'm going to showcase 00:24.000 --> 00:26.000 to you today. 00:26.000 --> 00:31.800 So we don't have much time, so let's demonstrate in, let's start answering the question 00:31.800 --> 00:33.600 of what is bloom. 00:33.600 --> 00:39.400 For that, I'm going to give you an overview of the project, and later we will get into detail. 00:39.400 --> 00:41.000 So bloom is a build system. 00:41.000 --> 00:47.600 It's a build system that supports project configuration, it supports gold-driven declarations, 00:47.600 --> 00:51.400 and it supports command-based actions. 00:51.400 --> 00:56.040 It's also a command dispatcher, as you can define your own commands, but you don't need 00:56.040 --> 00:59.800 the boiler plate of a configuration-based system. 00:59.800 --> 01:04.360 Here, as you can see, you don't need a configuration, you don't have it, and later we will 01:04.360 --> 01:06.280 see examples in detail. 01:06.280 --> 01:13.000 So more importantly, it is a framework to make your own build system. 01:13.000 --> 01:20.520 You can define your own buildable objects, and you can let bloom know what to do with them. 01:20.520 --> 01:27.600 So you may ask why another build system, and the answer is because it is minimalist and self-contained. 01:27.600 --> 01:31.600 In the image, you can see the dependencies of the bloom packets. 01:31.600 --> 01:36.680 At the top of the image, you can see that there is only one direct dependency of the packets, 01:36.680 --> 01:38.120 which is a guide. 01:38.120 --> 01:45.640 This means that bloom would trap itself, so the build system for bloom is bloom itself. 01:45.720 --> 01:49.920 Two is gold-based, you ask what you want, in the slides you can see that we are asking for 01:49.920 --> 01:55.160 a C binary, and blue will figure it out, we will figure out how to do it. 01:55.160 --> 02:01.480 It will understand what flux it needs to pass to create this type of object. 02:01.480 --> 02:02.480 Blue is extensible. 02:02.480 --> 02:07.320 This extensible through the Gile Object System, which provides us method of erriding 02:07.320 --> 02:13.880 predefinitions and inheritance, will also have user-defined commands that can override 02:13.920 --> 02:19.760 the building commands that we provide, so you don't like the defaults that we provide, you can change them. 02:19.760 --> 02:25.480 There will be a plug-in system that is yet to be done, and it will allow for changing things such as 02:25.480 --> 02:31.280 the custom build scheduler that the bloom has, you will be able to replace it for your own. 02:31.280 --> 02:36.080 The resource is a stencil system that I will showcase later. 02:36.080 --> 02:41.000 The resource of project serialization that allows to build external device, 02:41.000 --> 02:46.720 and we also have an auto-completion engine to improve the shell integration. 02:46.720 --> 02:50.440 So let's start with an example, a yellow blue example. 02:50.440 --> 02:58.360 We start with a blue-printed SEM file, this is similar to what a make-fall is for make. 02:58.360 --> 03:02.840 The blue-printed second-inner for gathering the blue project description. 03:02.840 --> 03:04.960 We start by importing stencil. 03:05.000 --> 03:09.640 A stencil is a guide module that provides a set of buildable types, 03:09.640 --> 03:13.640 and utilities that simplify the description of a command pattern. 03:13.640 --> 03:18.160 This example is going to be a CX sample, so we import the CX stencil. 03:18.160 --> 03:27.920 The greens give blue knowledge of a C binary, so we start by defining a yellow library, 03:27.920 --> 03:32.720 which is a C binary that takes a yellow dot C input, and produces a static, 03:32.960 --> 03:34.960 low dot A library. 03:34.960 --> 03:41.520 We also define a C binary object, that is the yellow, it will be, 03:41.520 --> 03:47.120 it will output the yellow artifact, and it takes, as it's input, a main dot C file, 03:47.120 --> 03:50.880 and the library object, which is defined. 03:50.880 --> 03:56.440 You can also define your own commands, which are actions that blue can execute. 03:57.400 --> 04:03.240 We gather everything together into a blue-printed object, that describes the blue project. 04:04.440 --> 04:08.840 So now let's try to build this project that we just described. 04:08.840 --> 04:11.880 As you can see, I got an exception. 04:11.880 --> 04:17.240 This is because the C stencils that we use, it requires a configuration step. 04:17.240 --> 04:21.720 This is a decision of the stencil, but it's not mandatory. 04:21.720 --> 04:25.720 As you can see, that there is an exception that gives a nice error message, 04:25.720 --> 04:31.080 with a hint, reminding the user that probably he forgot to configure. 04:32.360 --> 04:33.320 So let's do it right. 04:34.920 --> 04:40.280 Here we do blue configure build, they stand at a workflow that many of you will be familiar 04:40.280 --> 04:43.800 without the tools, and it does the configuration on the build. 04:44.520 --> 04:47.960 And you can notice that the commands can be changed with a double dash. 04:48.840 --> 04:52.120 This allows us to have commands that can take arguments. 04:52.440 --> 04:59.320 So in this example, I'm defining a geeks command that is just a blue command that invokes a geeks 04:59.320 --> 05:03.960 of process, and the arguments can be passed directly to this process. 05:05.960 --> 05:11.960 So you, some of you may think, what if my project needs a stateful data, such as a standard 05:11.960 --> 05:17.800 directory variable, like the prefix, bindir, or c flags, or other types of stateful data. 05:18.440 --> 05:22.120 So for that, we introduce the configuration object, which is a configuration, 05:22.120 --> 05:24.760 which is an object to store this type of data. 05:24.760 --> 05:27.000 In this slide, you can see an anticonfiguration. 05:28.360 --> 05:33.320 We can add variables in the variables slot, which takes a list of variables. 05:33.320 --> 05:37.400 In this example, we are defining a version variable that takes a string, 05:37.400 --> 05:43.560 but we are also defining a c flags variable that can be something more complex, such a procedure 05:43.560 --> 05:47.000 that depending on your first decides what are the flags that you need. 05:47.800 --> 05:52.360 We can also introduce project dependencies. 05:52.360 --> 05:56.040 So we have a slot for dependencies that takes a list of dependencies, 05:56.040 --> 05:59.720 since we are building a project with a list of c dependencies. 06:02.440 --> 06:05.320 Blue will ensure that this dependencies are met. 06:05.320 --> 06:10.680 Here, you can see an exception of blue telling us that it could not find the SDL2 dependency, 06:10.680 --> 06:13.800 and it gives us a message explaining why it could not find it. 06:13.800 --> 06:19.720 So now, let's make a configuration example, 06:19.720 --> 06:22.680 an example that uses this configuration object. 06:22.680 --> 06:25.400 We start with a white canvas, an empty blue print. 06:27.000 --> 06:34.200 We are our buildable object, and now we configure the c flags, 06:34.200 --> 06:38.440 the c extension that we are using, provides a default c flags. 06:38.440 --> 06:43.400 But in this case, we want to override the default and set the c flags to the O3 optimization. 06:44.760 --> 06:47.320 We are also a dependency for that. 06:47.320 --> 06:53.000 We include the dependency module, the brings blue, the knowledge of a c dependency. 06:53.000 --> 06:55.960 To the list of dependencies, we have this c dependency, 06:55.960 --> 07:00.760 and we specify a line 24 that the buildable object that we just defined 07:00.760 --> 07:02.600 requires this external dependency. 07:05.000 --> 07:08.760 So this is the, but how can we make use of this configuration? 07:09.720 --> 07:15.080 So let's define a command that makes use of these configured variables that I just showed you. 07:15.080 --> 07:19.800 And this is just an information command that brings us string to the SDL2. 07:19.800 --> 07:25.080 And we are referencing the different variables that are available to us, such as the source directory, 07:25.080 --> 07:29.000 build directory, the prefix, the c flags, and the like. 07:30.120 --> 07:31.960 We add this command to the list of commands. 07:33.720 --> 07:35.000 And we try to run it. 07:35.560 --> 07:41.400 If you pay attention, there is a configuration step where we are setting the prefix to a particular directory, 07:41.400 --> 07:43.640 the hello install in the temporal directory. 07:43.640 --> 07:48.280 And at the end of the screen, so you can see that the prefix has been updated. 07:50.840 --> 07:53.640 So now, we need to speak about delay computations. 07:53.640 --> 07:58.680 Because some of you may have noticed that there is some strange hint that you are not familiar with, 07:59.560 --> 08:02.280 which is this combination of characters. 08:02.680 --> 08:04.920 And this is what we call that delay computation. 08:06.040 --> 08:09.480 At the delay computation is an expression evaluated at runtime. 08:10.040 --> 08:12.040 So we have two steps. 08:12.040 --> 08:16.440 We have our configuration and later running of commands, a configuration is also command. 08:17.480 --> 08:23.720 And the configuration creates some state that we want to make use later when we are running 08:23.720 --> 08:29.560 other commands. So for simplifying this type of expressions, we have these delay computations. 08:29.880 --> 08:35.160 The tilde expression, which is the first one on the list that you have here, 08:35.160 --> 08:37.080 is to create the delay expression. 08:37.080 --> 08:42.360 Later, we have the question mark to retrieve a value of this state full data. 08:42.360 --> 08:48.040 For example, a symbol, the c flags, the prefix, and we also have an expression to an delay and expression. 08:48.040 --> 08:56.040 So within a delay computation, we can tell the blue to execute the expression now and do not wait 08:56.040 --> 08:58.520 until a later point after the configuration. 09:00.440 --> 09:04.760 Let's delay an expression. This is more or less the expansion you will get. 09:04.760 --> 09:09.880 You just need to know that this is something that will be evaluated later when we are running, 09:09.880 --> 09:11.160 not when we are configuring. 09:13.400 --> 09:18.200 So we make a more complex expression that is a delay expression that retrieves some values. 09:18.760 --> 09:21.480 You will see that the expansion gets much more complicated. 09:21.480 --> 09:27.000 This is not for you to understand. It is just to showcase that things to this mechanism, 09:27.000 --> 09:31.560 we can tame a lot of complexity and we can simplify these type of descriptions. 09:33.320 --> 09:39.000 So I wanted to draw some similarities. In make file, many of you will be familiar with assignment operator 09:39.000 --> 09:45.880 that assign variables in a later way and the expansion does not happen until they are used. 09:46.440 --> 09:50.600 In gigs, we have the expressions and in blue we have delay computations. 09:52.360 --> 09:56.120 So one last remark, delay computations are much more than variable expansion. 09:57.000 --> 10:02.520 They bring the power and expressibility of a guy and they can be serialized to this. 10:03.320 --> 10:06.920 This means that later they can be loaded and evaluated. 10:09.400 --> 10:10.920 Now let's speak about back traces. 10:12.520 --> 10:19.400 Many of us made mistakes and we made improvements to the gaile compiler, the gaile. 10:19.400 --> 10:27.000 We have all of you are actually made some of these improvements and now if you make a typo, 10:27.000 --> 10:31.880 such as in this example, I am introducing a variable I don't exist. This variable is some boundary. 10:32.680 --> 10:36.360 When we try to run it, we get this type of back trace, is telling us. 10:36.360 --> 10:40.760 While running command info, there is an unbound variable I don't exist. 10:41.080 --> 10:48.600 Add line 17 in this particular column highlighted by the red arrows, we get the back trace, 10:48.600 --> 10:55.880 that showcases the path that led to this exception. If we look back, we see the full back trace 10:55.880 --> 11:04.200 with the, well, these are back traces. We also have gel menus that are interactive. 11:05.000 --> 11:13.960 You can click the different elements and the hyperlink, they will bring you to the commands that you 11:13.960 --> 11:17.800 have defined and they understand user-defined commands, not only building commands. 11:18.920 --> 11:26.520 We also have replay functionality, so if we introduce an error, I introduce a variable that does not 11:26.520 --> 11:33.400 exist and when we build it, this is it through an exception and we can run replay to get a 11:33.400 --> 11:39.080 log of the failed objects and we can try to replay them individually with a going through the full 11:39.080 --> 11:48.360 build graph. There is also a preference system, a preference is a setting that the user can 11:49.000 --> 11:57.640 customize to set some customization of the customized aspect of blue. You can define them globally, 11:57.640 --> 12:02.200 you can define them project locally and you can also define them in an environment variable. 12:04.600 --> 12:11.160 There is also a big focus on extensive editing, so we have an inheritance system where we can 12:11.160 --> 12:15.880 define build the whole objects, in this case we are defining a texting for build the world, 12:15.880 --> 12:21.000 that extends the buildable class and we can add additional slots. Here I want you to pay attention 12:21.000 --> 12:26.600 that we have a type system, so you can specify the distance loss or strings or a list of strings. 12:27.160 --> 12:33.160 There is also a method of loading, blue knows how to build the manifest, build the buildable, 12:33.160 --> 12:38.760 but it does not know how to build our texting for buildable. So we overload the method that 12:38.760 --> 12:44.680 blue uses for building and we say that a buildable texting for object, it takes an input, 12:44.680 --> 12:49.960 it could be a list of inputs, it takes an output that could also be a list in our cases only one 12:50.840 --> 12:56.680 and we make our manifest, which is what really tells blue what to do with this object. 12:57.240 --> 13:03.160 We have a header which is the progress indicator that blue will print and we have also an action 13:03.240 --> 13:11.400 that generates the artifact. There is also blue.iel, which is an image interface that we created 13:11.400 --> 13:17.960 with the data serialization mechanism. We have blue rank command which is a completion read interface 13:17.960 --> 13:23.480 with smart completion based on the serialized data. There is also a transient menu that gets 13:23.480 --> 13:29.640 built dynamically, there is nothing hardcore here from the serialized data of the blueprint that is 13:29.640 --> 13:37.720 in a JSON format we create these menus. There is also a replay, a magnet, style menu interface 13:37.720 --> 13:44.600 with foldable sections, clickable buttons, and we also provide a gig support. We have the blue 13:44.600 --> 13:50.920 box channel which introduces the blue build system, which has a peculiarity which is that with the 13:50.920 --> 13:57.960 blue keyboard we can specify a relative path. So the build system does not introduce blue as a dependency 13:58.040 --> 14:03.960 and it can use the local sources to bootstrap blue itself and build your project in an embedded situation. 14:05.240 --> 14:13.400 The resources are faces which is we can specify a list of blue actions, blue commands and then 14:13.400 --> 14:20.200 they will get translated into a gig's faces. This is the discussed injected. So this allows the 14:20.200 --> 14:28.600 user to not have to do with transformations. So let's speak about the roadmap. Currently we are in 14:28.600 --> 14:34.920 the pre-alpha stage. This is because we want to stabilize the API. So we would like to get your feedback 14:34.920 --> 14:40.440 for the alpha that we are about to release. Later we will do a better release where we hope to have 14:40.440 --> 14:47.160 a more stable API and finally we will target a release candidate. The current features is that is 14:47.160 --> 14:51.320 purely written in-guile without additional dependencies. You show their replay functionality, 14:51.320 --> 14:56.680 they configureable preferences, they have a completion enzyme that I could not show because 14:56.680 --> 15:01.720 I didn't have time to open a shell. There is also the serialization data to create this external 15:01.720 --> 15:07.240 device. It's not only limited to image, you can do it, you can use it in other editors. There is 15:07.240 --> 15:15.400 an extensive old type in system. There is has based of buildable objects, but also time 15:15.400 --> 15:23.000 is termed based tracking of the inputs and outputs. There is also a configuration based on 15:23.000 --> 15:27.880 system discovery ability. So this is like the dependencies that could not be met based on the 15:27.880 --> 15:35.480 current environment we are running. The next feature is going to be to implement a build graph 15:35.480 --> 15:41.640 traversal API that we will allow many things that I don't have time to cover now. And we also 15:41.640 --> 15:49.640 plan to create some exporter of the build system. Great timing, sir. 15:49.640 --> 16:09.720 Those have three questions. 16:09.720 --> 16:11.720 It's the question yesterday. 16:11.720 --> 16:14.720 I'll tell you in it. 16:14.720 --> 16:18.720 If so, one of the constraints I've had would make is that sometimes, 16:18.720 --> 16:20.720 they give them a complaint about produce to outlets, 16:20.720 --> 16:23.720 they'd like to have them buy it on those internet fleet. 16:23.720 --> 16:26.720 And you can't spread that data target over one of the things. 16:26.720 --> 16:29.720 Is that an aspect that you've addressed on your statement? 16:29.720 --> 16:31.720 Uh, yes, I didn't have time to show you, 16:31.720 --> 16:34.720 but we can have multiple outputs. 16:34.720 --> 16:36.720 So it's been the volume objective. 16:36.720 --> 16:40.720 object, that is not limited to just string output. 16:40.720 --> 16:44.720 You can have a list of outputs, that the build system will track. 16:44.720 --> 16:46.720 Yeah. 16:46.720 --> 16:48.720 What about Windows support? 16:48.720 --> 16:50.720 Uh, the only dependencies guide. 16:50.720 --> 16:54.720 So this is a question for the maintainers of guide. 16:54.720 --> 16:56.720 Do you have work like this? 16:56.720 --> 17:00.720 In the range of people taking a build form and existing tools? 17:00.720 --> 17:02.720 Uh, is there a way to write this? 17:02.720 --> 17:12.720 I'm not sure if I understand that. 17:12.720 --> 17:16.720 So if I'm building my system with an existing build tool. 17:16.720 --> 17:18.720 Yeah. 17:18.720 --> 17:24.720 Yeah, I don't think I can do it incrementally. 17:24.720 --> 17:27.720 I mean, you can just blue to build parts of your project. 17:27.720 --> 17:30.720 You could use it for some sub-directories. 17:30.720 --> 17:32.720 But it can not read on make file. 17:32.720 --> 17:34.720 Okay. 17:46.720 --> 17:48.720 As a language, specific build system? 17:48.720 --> 17:52.720 For example, in the analytics through 14.99. 17:52.720 --> 17:56.720 Can we have a structure that you want to do? 17:56.720 --> 18:06.720 Um, I don't think that would make much sense because, you know, it's like, 18:06.720 --> 18:10.720 it's a really a replacement for auto tools. 18:10.720 --> 18:16.720 So there is no way without changing the sources of the thing that you want to build 18:16.720 --> 18:19.720 to make use of blue to build this thing. 18:19.720 --> 18:23.720 Especially because you need to let blue know what are the things that you want to build. 18:23.720 --> 18:25.720 You need to specify your build-able objects. 18:25.720 --> 18:27.720 For example, text info. 18:27.720 --> 18:29.720 Your tables, maybe. 18:29.720 --> 18:32.720 Your draft build-ables. 18:32.720 --> 18:35.720 So you will have to do some coding in blue. 18:35.720 --> 18:41.720 I want to understand the different build system requirements as we have. 18:47.720 --> 18:48.720 Okay. 18:48.720 --> 18:50.720 Thank you.