This message was deleted.
# configuration-cache
s
This message was deleted.
m
Documentation says
Copy code
A task input or output property or a script variable to capture the result of using project.rootDir to calculate the actual parameter.
But isn't that going to break build cache if the input ends up being an absolute path?
c
t
I've been told that rootDir is immutable and therefore safe from a cross-project perspective
m
projectLayout.getProjectDirectory()
isn't exactly what I want, I want the directory of the root project and this is not available in
ProjectLayout
or
ObjectFactory
. The closest I could find is make it relative and store it as a string input property: During configuration:
Copy code
task.projectRootDir.set(project.rootDir.relativeTo(project.projectDir).path)
And then in the task:
Copy code
val rootDir = projectLayout.projectDirectory.asFile.resolve(task.projectRootDir)
But that sounds like going through a lot of hoops
v
What don't you like with an absolute path? At least currently the configuration cache is not relocatable anyway.
c
BuildCache
🤦 1
☝️ 1
m
Exactly, I understand build cache will not like different String inputs on different machines
c
I'm slow now, but if the root directory is a File/Directory input you can use Normalization, don't you?
What is breaking my mind is..what you want to access to the rootProjectDir from a task in a subProject?
I mean, if you are looking for a config file, you can get the File directly (optionally with a provider)
v
Ah, build cache, yeah, that is problematic for a string-typed input of course. But noone said you need to have the input string-typed 🙂
m
if the root directory is a File/Directory input you can use Normalization
You mean the path sensitivity stuff? I don't really think it applies there. I don't really want an
@InputDirectory
on the root project dir or it's going to snapshot the whole project 😅 . And
@InputFile
is not going to work either I believe
what you want to access to the rootProjectDir from a task in a subProject?
This is a long story. The reason is mostly historical. We have a task that only takes input from the command line and one of them is a path. Initially, we had that path resolved relative to the current working directory but we found that in a few occasions, the cwd wasn't reliable (sometimes it was the cwd of the daemon and not the directory where
./gradlew
was run in). So the next choice was to use the directory where
./gradlew
is and most of the times it's the root project directory
v
Then maybe make it an internal
Directory
property and construct the actual
@Input...
property from that and the user input, because that is your actual input?
👍 2
m
That could work! Only using
rootProject
during configuration indeed 👍
Thanks!
👌 1
v
yw
c
InputFile with PathSensistivity.Relative wouldn't work? Would the snapshot be the full filetree?
(I am not saying it would, just asking)
v
Iirc you cannot use input file with a directory, what should that do? And it also works not really be correct for his use-case.
1
m
PathSensitivity documentation is all about file collections so not sure that'd work with a single
File
. Also not sure what Gradle would do if I put a
@InputFile
on a directory. Maybe it uses the absolute path as content to be snapshot but then I might as well use a string..;;
c
I was thinking a File can be either file or directory, so it should be fine used with Path sensitivity relative. But yeah, the internal + string input seems perfectly fine.
m
What would it be relative to if it's a single File?
c
Like any file. I don't know if that's to project or root.. 🤔
m
My understanding of the doc
Copy code
For files in directories in the root of the file collection, the normalized path is the relative path of the file to the root directory containing it.
is that
PathSensitivity.RELATIVE
is mainly for `SourceDirectorySet`where you can call
srcDir
to add root directories
v
Path sensitivity should work fine for
@InputFile
and have the same effect as on
@InputFiles
for example. But as I said, I believe configuring a directory for an
@InputFile
will result in an error and if it does not, it should as it just does not make sense.
👀 1