Okay, so hello everyone, I'm Sergio Pasta Perez, and today I'm going to present a
U-blue, a generic build system crafted entirely in guide.
We've been developing this project over the past year, alongside my friend Oliver Tion,
which is actually the skin wizard behind any of the features I'm going to showcase
to you today.
So we don't have much time, so let's demonstrate in, let's start answering the question
of what is bloom.
For that, I'm going to give you an overview of the project, and later we will get into detail.
So bloom is a build system.
It's a build system that supports project configuration, it supports gold-driven declarations,
and it supports command-based actions.
It's also a command dispatcher, as you can define your own commands, but you don't need
the boiler plate of a configuration-based system.
Here, as you can see, you don't need a configuration, you don't have it, and later we will
see examples in detail.
So more importantly, it is a framework to make your own build system.
You can define your own buildable objects, and you can let bloom know what to do with them.
So you may ask why another build system, and the answer is because it is minimalist and self-contained.
In the image, you can see the dependencies of the bloom packets.
At the top of the image, you can see that there is only one direct dependency of the packets,
which is a guide.
This means that bloom would trap itself, so the build system for bloom is bloom itself.
Two is gold-based, you ask what you want, in the slides you can see that we are asking for
a C binary, and blue will figure it out, we will figure out how to do it.
It will understand what flux it needs to pass to create this type of object.
Blue is extensible.
This extensible through the Gile Object System, which provides us method of erriding
predefinitions and inheritance, will also have user-defined commands that can override
the building commands that we provide, so you don't like the defaults that we provide, you can change them.
There will be a plug-in system that is yet to be done, and it will allow for changing things such as
the custom build scheduler that the bloom has, you will be able to replace it for your own.
The resource is a stencil system that I will showcase later.
The resource of project serialization that allows to build external device,
and we also have an auto-completion engine to improve the shell integration.
So let's start with an example, a yellow blue example.
We start with a blue-printed SEM file, this is similar to what a make-fall is for make.
The blue-printed second-inner for gathering the blue project description.
We start by importing stencil.
A stencil is a guide module that provides a set of buildable types,
and utilities that simplify the description of a command pattern.
This example is going to be a CX sample, so we import the CX stencil.
The greens give blue knowledge of a C binary, so we start by defining a yellow library,
which is a C binary that takes a yellow dot C input, and produces a static,
low dot A library.
We also define a C binary object, that is the yellow, it will be,
it will output the yellow artifact, and it takes, as it's input, a main dot C file,
and the library object, which is defined.
You can also define your own commands, which are actions that blue can execute.
We gather everything together into a blue-printed object, that describes the blue project.
So now let's try to build this project that we just described.
As you can see, I got an exception.
This is because the C stencils that we use, it requires a configuration step.
This is a decision of the stencil, but it's not mandatory.
As you can see, that there is an exception that gives a nice error message,
with a hint, reminding the user that probably he forgot to configure.
So let's do it right.
Here we do blue configure build, they stand at a workflow that many of you will be familiar
without the tools, and it does the configuration on the build.
And you can notice that the commands can be changed with a double dash.
This allows us to have commands that can take arguments.
So in this example, I'm defining a geeks command that is just a blue command that invokes a geeks
of process, and the arguments can be passed directly to this process.
So you, some of you may think, what if my project needs a stateful data, such as a standard
directory variable, like the prefix, bindir, or c flags, or other types of stateful data.
So for that, we introduce the configuration object, which is a configuration,
which is an object to store this type of data.
In this slide, you can see an anticonfiguration.
We can add variables in the variables slot, which takes a list of variables.
In this example, we are defining a version variable that takes a string,
but we are also defining a c flags variable that can be something more complex, such a procedure
that depending on your first decides what are the flags that you need.
We can also introduce project dependencies.
So we have a slot for dependencies that takes a list of dependencies,
since we are building a project with a list of c dependencies.
Blue will ensure that this dependencies are met.
Here, you can see an exception of blue telling us that it could not find the SDL2 dependency,
and it gives us a message explaining why it could not find it.
So now, let's make a configuration example,
an example that uses this configuration object.
We start with a white canvas, an empty blue print.
We are our buildable object, and now we configure the c flags,
the c extension that we are using, provides a default c flags.
But in this case, we want to override the default and set the c flags to the O3 optimization.
We are also a dependency for that.
We include the dependency module, the brings blue, the knowledge of a c dependency.
To the list of dependencies, we have this c dependency,
and we specify a line 24 that the buildable object that we just defined
requires this external dependency.
So this is the, but how can we make use of this configuration?
So let's define a command that makes use of these configured variables that I just showed you.
And this is just an information command that brings us string to the SDL2.
And we are referencing the different variables that are available to us, such as the source directory,
build directory, the prefix, the c flags, and the like.
We add this command to the list of commands.
And we try to run it.
If you pay attention, there is a configuration step where we are setting the prefix to a particular directory,
the hello install in the temporal directory.
And at the end of the screen, so you can see that the prefix has been updated.
So now, we need to speak about delay computations.
Because some of you may have noticed that there is some strange hint that you are not familiar with,
which is this combination of characters.
And this is what we call that delay computation.
At the delay computation is an expression evaluated at runtime.
So we have two steps.
We have our configuration and later running of commands, a configuration is also command.
And the configuration creates some state that we want to make use later when we are running
other commands. So for simplifying this type of expressions, we have these delay computations.
The tilde expression, which is the first one on the list that you have here,
is to create the delay expression.
Later, we have the question mark to retrieve a value of this state full data.
For example, a symbol, the c flags, the prefix, and we also have an expression to an delay and expression.
So within a delay computation, we can tell the blue to execute the expression now and do not wait
until a later point after the configuration.
Let's delay an expression. This is more or less the expansion you will get.
You just need to know that this is something that will be evaluated later when we are running,
not when we are configuring.
So we make a more complex expression that is a delay expression that retrieves some values.
You will see that the expansion gets much more complicated.
This is not for you to understand. It is just to showcase that things to this mechanism,
we can tame a lot of complexity and we can simplify these type of descriptions.
So I wanted to draw some similarities. In make file, many of you will be familiar with assignment operator
that assign variables in a later way and the expansion does not happen until they are used.
In gigs, we have the expressions and in blue we have delay computations.
So one last remark, delay computations are much more than variable expansion.
They bring the power and expressibility of a guy and they can be serialized to this.
This means that later they can be loaded and evaluated.
Now let's speak about back traces.
Many of us made mistakes and we made improvements to the gaile compiler, the gaile.
We have all of you are actually made some of these improvements and now if you make a typo,
such as in this example, I am introducing a variable I don't exist. This variable is some boundary.
When we try to run it, we get this type of back trace, is telling us.
While running command info, there is an unbound variable I don't exist.
Add line 17 in this particular column highlighted by the red arrows, we get the back trace,
that showcases the path that led to this exception. If we look back, we see the full back trace
with the, well, these are back traces. We also have gel menus that are interactive.
You can click the different elements and the hyperlink, they will bring you to the commands that you
have defined and they understand user-defined commands, not only building commands.
We also have replay functionality, so if we introduce an error, I introduce a variable that does not
exist and when we build it, this is it through an exception and we can run replay to get a
log of the failed objects and we can try to replay them individually with a going through the full
build graph. There is also a preference system, a preference is a setting that the user can
customize to set some customization of the customized aspect of blue. You can define them globally,
you can define them project locally and you can also define them in an environment variable.
There is also a big focus on extensive editing, so we have an inheritance system where we can
define build the whole objects, in this case we are defining a texting for build the world,
that extends the buildable class and we can add additional slots. Here I want you to pay attention
that we have a type system, so you can specify the distance loss or strings or a list of strings.
There is also a method of loading, blue knows how to build the manifest, build the buildable,
but it does not know how to build our texting for buildable. So we overload the method that
blue uses for building and we say that a buildable texting for object, it takes an input,
it could be a list of inputs, it takes an output that could also be a list in our cases only one
and we make our manifest, which is what really tells blue what to do with this object.
We have a header which is the progress indicator that blue will print and we have also an action
that generates the artifact. There is also blue.iel, which is an image interface that we created
with the data serialization mechanism. We have blue rank command which is a completion read interface
with smart completion based on the serialized data. There is also a transient menu that gets
built dynamically, there is nothing hardcore here from the serialized data of the blueprint that is
in a JSON format we create these menus. There is also a replay, a magnet, style menu interface
with foldable sections, clickable buttons, and we also provide a gig support. We have the blue
box channel which introduces the blue build system, which has a peculiarity which is that with the
blue keyboard we can specify a relative path. So the build system does not introduce blue as a dependency
and it can use the local sources to bootstrap blue itself and build your project in an embedded situation.
The resources are faces which is we can specify a list of blue actions, blue commands and then
they will get translated into a gig's faces. This is the discussed injected. So this allows the
user to not have to do with transformations. So let's speak about the roadmap. Currently we are in
the pre-alpha stage. This is because we want to stabilize the API. So we would like to get your feedback
for the alpha that we are about to release. Later we will do a better release where we hope to have
a more stable API and finally we will target a release candidate. The current features is that is
purely written in-guile without additional dependencies. You show their replay functionality,
they configureable preferences, they have a completion enzyme that I could not show because
I didn't have time to open a shell. There is also the serialization data to create this external
device. It's not only limited to image, you can do it, you can use it in other editors. There is
an extensive old type in system. There is has based of buildable objects, but also time
is termed based tracking of the inputs and outputs. There is also a configuration based on
system discovery ability. So this is like the dependencies that could not be met based on the
current environment we are running. The next feature is going to be to implement a build graph
traversal API that we will allow many things that I don't have time to cover now. And we also
plan to create some exporter of the build system. Great timing, sir.
Those have three questions.
It's the question yesterday.
I'll tell you in it.
If so, one of the constraints I've had would make is that sometimes,
they give them a complaint about produce to outlets,
they'd like to have them buy it on those internet fleet.
And you can't spread that data target over one of the things.
Is that an aspect that you've addressed on your statement?
Uh, yes, I didn't have time to show you,
but we can have multiple outputs.
So it's been the volume objective.
object, that is not limited to just string output.
You can have a list of outputs, that the build system will track.
Yeah.
What about Windows support?
Uh, the only dependencies guide.
So this is a question for the maintainers of guide.
Do you have work like this?
In the range of people taking a build form and existing tools?
Uh, is there a way to write this?
I'm not sure if I understand that.
So if I'm building my system with an existing build tool.
Yeah.
Yeah, I don't think I can do it incrementally.
I mean, you can just blue to build parts of your project.
You could use it for some sub-directories.
But it can not read on make file.
Okay.
As a language, specific build system?
For example, in the analytics through 14.99.
Can we have a structure that you want to do?
Um, I don't think that would make much sense because, you know, it's like,
it's a really a replacement for auto tools.
So there is no way without changing the sources of the thing that you want to build
to make use of blue to build this thing.
Especially because you need to let blue know what are the things that you want to build.
You need to specify your build-able objects.
For example, text info.
Your tables, maybe.
Your draft build-ables.
So you will have to do some coding in blue.
I want to understand the different build system requirements as we have.
Okay.
Thank you.