We are experiencing really long build times. I realize that when a header changes anything that includes that header has to be recompiled but changing a single line of code typically takes 5 minutes to recompile. We experience this on multiple computers. Is this the new norm or do we have something messed up in our project?
I’m struggling to find a way to get Gradle to provide more verbose information during compile time that might shed some light on this. Is there a way to dig into the build and determine what is taking so long to compile?
FWIW, I have noticed that CPP build times feel much longer than prior years.
We are using the deploy robot command to build our code even if we don’t have a robot attached to try and speed up the process. I believe this only builds the release profile for the robot, and not the debug profile.
If anyone knows how to disable the debug profile permanently in gradle, I’m all eyes…
I’m concerned about trying to iterate autos on the practice field with these build times. We can obviously put gains and tune with the dashboard but logic and other code changes are going to kill us.
Agreed. We put a bunch of smart dash parameters in for tuning and then lock them in once we are happy, removing most of them from the code for competition.
Until someone comes up with a bazel build system, that’s the best we have come up with.
You should be able to use the Gradle tasks command to find the name of the specific build task to run, so it doesn’t run for all architectures and debug/release.
I’m not anywhere near a computer but that seems reasonable. Note that Gradle tasks have dependencies, so when running deploy, it will run the appropriate build step so you only need to run deploy. Running just the single build step should be faster then running all of them.
Sorry for all the back and forth…but how does deploy know whether to deploy Debug / Release? We would love to avoid building debug builds unless we actually need them.
Deploy only builds release unless the debug flag is set when invoking gradle. It does this because it has the component it’s expecting to deploy, and can iterate through that component finding the roborio release build and only grabbing a dependency on that. Whereas build grabs a dependency on all components, all those components binaries, including all the different build types.
One thing to note is that in generate C++ build times are 1-2 seconds per file at minimum. Many of the odometry features added this season are template and file heavy, which can increase that to 5-10 seconds per file including any of the odometry headers.
In addition, gradle does do a lot more building then is fully requires, especially if you have desktop support enabled. As everyone sees, it builds both debug and release for all platforms. It does this, because when you just run build, it has no clue what you actually want to do. In addition, enabling desktop enables unit tests by default, and when gradle builds unit tests it builds a completely separate copy of the executable, mainly so it can remove the main function. Because of this, adding desktop actually adds 4 builds, not 2.
I can look into adding a build roborio release exclusively button, that might not be too bad, but it would be a 2021 thing. Just running deploy does work, and will only build the roborio release build.
I’m not familiar with Gradle but you can dramatically speed up build times if you can coax it into doing parallel builds. Similar to the -jN flag in gnumake.