Question: given a

Settings

object (or

BuildLayout

), on what occasion would the root directory be different from the settings directory? I have an unusual Gradle project that symlinks its settings file, and I have a feeling it's compensating for something, and learning such distinction would prove useful.

the root directory is the project directory of the root project the settings directory is the directory in which the settings script is in if you for example change the project directory of the root project in the settings script, those directories will be different.

And while it's deprecated, there's also still the

--settings-file

command-line argument which I suppose could change things too

Is the reason

--settings-file

is deprecated to discourage people from fiddling around with it, or are there concrete plans to strongly associate the settings directory with "the directory where the

gradlew

script is located" or the "current working directory" or somesuch? Again, I ask because I have an unusual project that symlinks

gradlew

, symlinks

settings.gradle

, symlinks

build.gradle

, and symlinks other directories like

buildSrc

.

And while it's deprecated, there's also still the

--settings-file

command-line argument which I suppose could change things too

It should not change much. The root project by default has the settings dir as project dir. So if you specify a settings script from another location, that location is the settings dir and thus the root project dir. So again it depends on whether that settings script reconfigures the root project build script or not.

Is the reason

--settings-file

is deprecated to discourage people from fiddling around with it

Pretty much, because you would always need to give this and / or

--build-file

on each invocation and also from IDE and other tools to get the build right. See https://github.com/gradle/gradle/issues/16402 for the full reasoning.

with "the directory where the

gradlew

script is located"

Surely not, where this script is located is totally irrelevant. You can also put it in a subdirectory and call it like

subdirectory/gradlew

if you prefer, this is just non-standard and will confuse everyone else 😄 If you meant "with the root project directory", I don't think so, as you can still customize the build layout / root project directory from within the settings script.

or the "current working directory" or somesuch?

This basically is the case. Not in the sense that the settings script has to be in the current working directory, as it is also searched upwards unless you disable it, so that you can invoke Gradle from a subproject directory.

So it looks like there might not be a way around symlinking the settings file in my use case, but it seems like there is a way I can get rid of the practice of symlinking the build file, or

buildSrc

, or even

gradlew

. Does that sound right?

Hard to say, as I have no idea what is symlinked from where to where and why. I'd tend to say you should get away without symlinking at all.

Sorry, probably should describe the layout a bit more. I have a weird setup where I have two subdirectories,

mainProject

and

subProject

, for which the symlinks point to

mainProject

- ie. there is a symlink from

settings.gradle.kts

to

mainProject/settings.gradle.kts

and so on, and

subProject

is just added as a plain old

include(":subProject")

therein.

Still don't understand why you should need a symlink :-)

I think it's a product of a bygone era, where symlinks exist to mimic a Gradle project layout while having the actual stuff elsewhere, so that things like

./gradlew :subProject:build

looks like it would make sense. But at an abstract level, it could probably be reworked.

It could always have been done without symlinks I'd say. You just need to set the project directories in the settings script how you want them to be.

That's fair. I think the hardest part to let go is probably associating the settings directory to the root of this weird setup.