From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

depends on the context.  it’s just a directory at the end of the day.  however, if you call project.rootDir in some locations that pulls in the project object, which isn’t CC safe.  Often find it safest (and more future proof) to use `layout` for directory locations.

in this case I'm reviewing a PR and someone wants to store a config file in a centralized location. They're doing this at configuration time, not task execution, so there shouldn't be an issue accessing the `Project` instance. I was just wondering about the `getRootDir()` part

if it’s done at configuration time Gradle will try and avoid that work with CC, so everything in play is potentially a problem.  Also unclear the different between rootDir and projectDir (don’t often see rootDir, can’t recall ever using it).

for other similar items have used a custom task to handle this.

<https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements> gives a replacement for `rootDir` so looks like it's not cc-safe

Ah well, never mind, you're reading it at configuration time

not sure what will happen - perhaps it will be fine, as it isn’t a captured input.

cleanest to have these kind of actions pulled out into tasks - that way you can clearly see configured inputs separate from executed code.

I'm not sure what you're talking about when you say "actions pulled out into tasks." As I said, the rootDir is being used to hold onto some global configuration files.

fair enough, i have limited understanding of the specifics.  had assumed it was storing some global configuration.

to be specific, it has proguard configuration files. They're the same regardless of the subproject they're being used in

Are you writing a global file during configuration? That seems like a dangerous side effect?

Also work that's going to be executed every build so not super efficient

in that case, make it a ValueSource so that CC will cache the results.

Reading at configuration seems ok to me. If not, writing something like
```A task input or output property or a script variable to capture the result of using project.rootDir to calculate the actual parameter```
would be kind of misleading

the rootDir ought to be immutable. It's just a `File` reference

it's not like buildDir or projectDir, which are mutable

I have a task which needs a File input. I feel like this should be safe, but I just wanted to confirm because anything that reaches out of the project dir hierarchy feels a bit sketchy to me, by default, until proven otherwise

I think it's be fine to do `Project.getRootDir()`  during config time.

FTR `layout.projectDirectory` is immutable and for reaching the root dir I would nowadays do `rootProject.layout.projectDirectory` . Although that feels even more "dirty" due to the "rootProject" in there. That's why there is <https://github.com/gradle/gradle/issues/13654> which unfortunately no one ever added yet.

(something to follow and give a :+1: )

Accessing `project.rootDir` at configuration time is not a problem for CC at all.
If you use it to create a File input for a task, no need for a value source.