I'm trying to split my build.gradle.kts into multiple files, but while the gradle script does run wh...

# gradle

[martmists]

I'm trying to split my build.gradle.kts into multiple files, but while the gradle script does run when split and using apply(from="/path/to/file.gradle.kts") , I don't seem to get any syntax highlighting or other IDA features. Is there a different way I should split gradle scripts?

[christophsturm]

its recommended to use convention plugins: https://docs.gradle.org/current/samples/sample_convention_plugins.html

[martmists]

From experience using a buildSrc for setting up stuff massively increases build time from 10 seconds to several minutes, is there really no better way to do it?

[no]

Included builds are the other option

[Vampire]

Using buildSrc should not cause such a massive increase. If it does, that's probably fishy. But yeah, I usually also use included builds instead of buildSrc.

[martmists]

how do included builds work? I know that's how it works for subprojects, but I've never seen it used for splitting up the logic for root build.gradle.kts

[Vampire]

know that's how it works for subprojects

Not really.
Don't confuse subprojects (include) with subbuilds / composite builds (includeBuild).
Composite builds are used to provide an ad-hoc replacement for a binary dependency.
Whether this dependency is a normal dependency or a plugin does not matter much.

If you apply a plugin (including precompiled script plugins), it is searched in the included builds and if found, it is built and used.
Opposed to buildSrc it does only the work necessary, meaning it only builds the necessary jars, not all jars in the build and it does not always run the tests like buildSrc.
And it also just adds the built jar to the build script class path where it is necessary not to all build script class paths like buildSrc.

Actually for normal project plugins you can include the build like a build for a dependency too in the settings script top-level,
but if your Gradle is recent enough you should better do it within the pluginManagement block.

[gildor]

Included build is indeed an option which I like more than buildSrc, but does it really has any performance improvements comparing to buildSrc? I always thought that it more or less equivalent

[Vampire]

Depends on what you do.
If you
• have all code that would have been in buildSrc in the same project of the included build
• use something from that included build in each and every build script (does not have to be the same something, just every build script needs to use something from the included build)
• do not have tests
then it should be basically the same unless I forgot a detail.

• buildSrc is always built before the main build
• its tests are always execute (not if they are up-to-date of course, but the task is in the task graph)
• it is added to all build script class paths thus influencing their class path if anything changes in buildSrc
An included build
• is only built if it is actually used
• only what is necessary is done (the jar built, if you want to execute tests you need to wire that separately)
• it is only added to the build script class paths that actually use it
• if you split your stuff into multiple artifacts in the included build or into multiple included builds, it is even more separated
if you for example have build scripts A, B, C, and D and that use the plugins a, b, c, and d from included build where all are in one artifact, then if you change b, the class path of all 4 build scripts changes
if a, b, c, and d are in different artifacts, then if you change b, only the build script class path of B changes, ...