https://gradle.com/ logo
Join Slack
Powered by
I might be going insane but what precisely does "b...
# community-support
t
I might be going insane but what precisely does "build", the noun, mean in Gradle?
To my surprise I cannot find the definition of the noun "build" in the documentation, even though it is used many times everywhere. I am not new to Gradle neither, but more I think about it the more confused I get
I (now vaguely) understand "build" as "execution of a collection of tasks", referring to the act itself. However this definition wouldn't work for understanding parts of the documentation, for instance "A typical multi-project build has the following layout (...)", because an execuction of task does not have a "file system layout"
Some of the sentences in the documentation drives me insane even though I suppose I understand what the author is trying to express, here for example: > When a 
buildSrc
directory is present at the root of a Gradle build, Gradle treats it as a Composite Build. Upon detecting the 
buildSrc
directory, Gradle: (...) (source)
When a 
buildSrc
directory is present at the root of a Gradle build, (...)
A "build's root"? So a "build" is a directory? I suppose they meant to say: "When a 
buildSrc
directory is present under a root project's directory"
> ..., Gradle treats it as a Composite Build. A "Composite build" is a build that includes another build; an "Included build" is a build that got included in a Composite Build setup. I suppose they meant to say: "Gradle treats it as an Included Build"
v
A build is what you define in the settings script. The collection of protects that make up one build. A composite build is the whole consisting of an including build and an included build (or multiple each).
t
This definition feels way too blurry
It sounds right that a "settings script defines the project strcture and the projects involved in a build", but to say that "a build is what we define in a settings script" doesn't feel precise
because we could say we define a build with build scripts, and the property files, and command line arguments etc...
v
All the build scripts and property files are part of the build, yes. And they configure the build. But they don't define the build. Build scripts per-se are optional, a project is a project when it is included in the settings script, whether it has an explicit build script or not. I don't see at all where the definition is blurry at all, the whole thing is called a "build". In Maven terminology you would say "project" for what is a "build" in Gradle speak.
t
So a "build" is an instance of the 
Settings
interface in Gradle API? 🤔
v
No
A build is nothing you have in code, it is the whole "thing"
t
So... the entire Gradle project?
v
The entire Gradle build
t
like an alias for "Root project"?
v
A project is a sub-thing of the build
And no, the root project is just one of the projects in the build
The build is all projects and settings and ...
t
So a build is the entire environment we define for a root project?
I'm having trouble defining "build" in a single sentince precisely...
v
Again, a build consists of 1-n projects. The root project is just one of those projects. The build is the entirety of all projects, settings, and so on.
t
Mhm yeah I'm aware of that
v
Doesn't sound like it as you continuously try to get back to defining the root project as the build. 🙂
t
Hmm I suppose I used a wrong word, maybe I should have said a "project tree" or something 🤔
Like, all below a root project
v
The projects are the parts of the build and they form a tree, yes
t
How about "complete set of configuration files that define how a project should be built"?
Hmm come to think of it, would you consider run time, command line arguments a part of a build? 🤔
v
The configuration files are not the build, they configure the build. And the command line arguments steer what parts of the build to execute and in which way.
⭐ 1
t
Should sources and resources of a project be considered a part of a build?
Hmm I think they shouldn't be because we could create gradle projects with only gradle scripts and it would work just fine
v
Just like the configuration scripts and so on, they are inputs of the build. So you could consider the sources and the parameters and so on as part of the build, or you can just consider them as inputs for the build. Whether one should say they are "part" of the build is probably more a philosophical question. 😄
👀 1
a
To my surprise I cannot find the definition of the noun "build" in the documentation
There is a definition in the glossary, but I'll let you decide whether it's useful or not :) https://docs.gradle.org/current/userguide/glossary.html#b
🙌 1
t
Oh right I could just search on the glossary! This whole time I was using the user guide search function 😅
Apart from "Build" there is a separate definition for "Gradle Build"... No idea how they are different
Build
A build is the aggregate of the atomic pieces of work performed by Gradle. It is made up of projects and those projects have a collection of tasks.
A build usually has an outcome of SUCCESS or FAILURE.
You can run a build using the 
gradle
or 
gradlew
commands.
Gradle Build
A Gradle build can consist of one or more Gradle projects and is typically configured using a 
settings.gradle(.kts)
file at the root.
When invoked, the Gradle build executes a set of tasks based on the defined build logic, often using the Gradle Wrapper (
./gradlew
).
v
They are not. But I'd recommend reporting a doc issue that this is defined twice and with different working. One should just point to the other imho.
j
I would read that as 1st one is the build process, and 2nd one is the set of source files (
.gradle(.kts)
and others e.g. 
gradle.properties
) that are evaluated/executed during a build process. Not the same thing, but closely related.
v
No, both describe exactly the middle between the two statements you just did. The files (your second half) configure the build, which is the pieces of work, which when executed are the process of building (your first half).
j
Ah, these kind of arguments are at least as old as Heraclitus — when you jump in a river, do you mean the water of the river, or the bed of the river? Or is the river yet another thing? 🤔 good night 😄
v
Wasn't Heraclitus more that you cannot run the same Gradle build twice? 🤔
Open in Slack
PreviousNext
Powered by