This message was deleted.

I think it depends on whether it's a FileCollection (which can contain anything) or FileTree (which have a customisable root dir). But in practice it's usually relative to the current project dir. So if you have a project

/full/path/to/my-project

with a subproject

/full/path/to/my-project/subproject-x/

that has a task that creates an output file

/full/path/to/my-project/subproject-x/build/foo/output.txt

then

RELATIVE

will relativise it to be

build/foo/output.txt

So if I have a set of source files under

~/java

, 2 builds in 2 different directories won't be able to share their build cache?

maybe, if you created a FileTree with the root dir set to be

~/java

and then added that to your CFC

But then what if I do:

configurableFileCollection.from("$HOME/java")
configurableFileCollection.from("$HOME/java/dir/Foo.java")

Is it going to throw?

do you mean throw an exception?

I would expect the normalizer to throw an exception if the same path is reachable through 2 roots like in

configurableFileCollection.from("$HOME/java")
configurableFileCollection.from("$HOME/java/dir/Foo.java")

I think your code would add both the dir

~/java

and the file (assuming you're setting the home dir manually because I don't think

$HOME

works in Java)

I think your code would add both the dir

~/java

and the file

So it's going to compile my

Foo.java

file twice? Maybe... I can try

I think it will just de-dupe the file

But if it "dedupes", what is the normalized path?

configurableFileCollection.from("$HOME/java")

will add

Foo.java

and then the second operation will 'overwrite' the first with the second

Use the last?

oh, I think the normalization is done at a different phase, so maybe we're talking past each other

https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/PathSensitivity.html#RELATIVE

The property is an input directory. 
* The path of the files in the input directory are considered relative to the input directory.

I guess my question is: what if the property is a

ConfigurableFileCollection

at some point Gradle inspects the task inputs to determine the fingerprint of the input. And if it sees a collection of files it will fingerprint it based on the path sensitivity. But that's unrelated to how files get added into a CFC, which I assume works as a 'last file wins' kind of thing

But that's unrelated to how files get added into a CFC

I don't think it is because I would expect the normalised path to be the relative path inside the CFC.

I think a CFC will contain Java File objects, so there won't be a 'root' dir, and the files are added as plain Java Files - no modification. A FileTree is a subtype of a FileCollection, with an additional property: the root dir. So the path sensitivity setting doesn't have any input how a CFC works. There's no path norming until Gradle starts fingerprinting task inputs.

Interesting. So the below would make no sense, right?

@get:InputFiles
  @get:PathSensitive(PathSensitivity.RELATIVE)
  abstract val files: ConfigurableFileCollection

that makes sense to me :) You've got a collection of files that might contain directories or files. At some point Gradle will traverse the directories and get the files contained. So if you add these to a CFC:

/full/path/java/
/full/path/java/Z.Java

Then you'll have a CFC that contains some files:

/full/path/java/some/package/X.Java
/full/path/java/some/other/package/Y.Java
/full/path/java/Z.Java

And then when the task run Gradle tries to fingerpint the task inputs. Gradle knows which subproject owns the task, so it knows the project directory. And Gradle can also see the pathsensitivity setting. So it will get all the files in the CFC, and if the path sensitive is RELATIVE then it will be something like this.

../../../java/some/package/X.Java
../../../java/some/other/package/Y.Java
../../../java/Z.Java

Then it will hash the paths (and the file contents) to get the fingerprint

if the path sensitive is RELATIVE then it will be something like this

Fair assumption. My issue if it works like this is that if I clone my repo in a subdir, the normalized paths will now become (notice the extra

../

)

../../../../java/some/package/X.Java
../../../../java/some/other/package/Y.Java
../../../../java/Z.Java

And my build cache doesn't work any more

yes, that makes sense to me

I'll run a few experiments and report back

maybe if you create a FileTree

objects.fileTree().apply { 
    this.setDir("$HOME/java")
}

and add it to the CFC then Gradle will be cleverer - but I suspect it will just treat the FileTree as a list of java.io.Files and you'll have the same problem - the CFC will contain a lot of files (with absolute paths dependent on the project location) that will later be normalized. Maybe if you have a DirectoryProperty as a task input then Gradle will normalize the files contained in the dir relative to the provided dir? (Similar for a ConfigurableFileTree). Pure guesses. I have no idea what will actually work. I'm curious what you find!

So it turns out I can share my build cache so Gradle is clever . (gist)

great! Haha so all of my theorising was nonsense?

I think a CFC is "rooted"

I think this is the relevant bit code that fingerprinting files when RELATIVE is used https://github.com/gradle/gradle/blob/v8.5.0/platforms/core-execution/snapshots/src/main/java/org/gradle/internal/fingerprint/impl/RelativePathFingerprintingStrategy.java#L57-L82 I think it works by iterating through all of the files within any file collection and will compute a common root-dir shared between all of them, and then use that to compute the relative paths of all files to the root dir. So you could move the directory

~/java/

anywhere on the filesystem - the relative paths would still all be the same relative to the new location of

<...>/java/

.

FWIW, the roots is gotten from https://github.com/gradle/gradle/blob/fc63c5e5edb023351e25c73188fa0d9386972b0e/sub[…]internal/fingerprint/impl/DefaultFileCollectionSnapshotter.java My understanding is that internally

FileCollection

contains

FileTrees

and the roots of those

FileTrees

are used for normalization. Alas I haven't found a way to access those roots using only public API