cache generated file paths relative to the build directory (changed from project directory) #979
Conversation
RBusarow
force-pushed
the
rick/relative-build-dir
branch
2 times, most recently
from
fedf561
to
7999b03
Compare
|
|
…rom project directory) A project's build directory can be reassigned to something other than `<the project>/build`. This would typically be done via some build logic that's checked in to source control and applied to any machine that builds the code. This would usually mean that all machines' build directories have the same path relative to the project root. However, it's possible to build directory to be re-mapped in other ways, that result in a different relative path. When this happens, the paths for source/generated files must be cached as their paths relative to the build directory, instead of the project.
RBusarow
force-pushed
the
rick/relative-build-dir
branch
from
7999b03
to
b28e657
Compare
| get() = tables.getSourceFilesWithoutGeneratedContent() | ||
| .filter { source -> source != RelativeFile.ANY } | ||
| .toSet() | ||
| .mapNotNullToSet { it.absolute() } |
There was a problem hiding this comment.
Do we not need to check for AbsoluteFile.ANY_ABSOLUTE like we were for the old RelativeFile marker? I couldn't tell from the other changes if this is just not needed anymore or if it's happening implicitly somewhere
There was a problem hiding this comment.
Good question. It's happening implicitly elsewhere, but it also doesn't matter since ANY_ABSOLUTE actually gets added to this set downstream in case it didn't exist already.
| @Deprecated("no", ReplaceWith("absolute")) | ||
| fun GeneratedFileWithSources.toSourceFile(): AbsoluteFile = absolute |
There was a problem hiding this comment.
Why deprecate this instead of just replacing the usages now?
There was a problem hiding this comment.
I sometimes do this to get IDE help with a simple migration, but I forgot to delete the leftover function afterwards. I'll clean this up in a followup PR.
There was a problem hiding this comment.
Followup PR here: #979 (comment)
| task(":compileKotlin")?.outcome shouldBe TaskOutcome.SUCCESS | ||
| } | ||
|
|
||
| rootA.path.deleteRecursivelyOrFail() |
There was a problem hiding this comment.
Why do we delete the rootA files here? My initial reaction based on the rest of the setup is that the project A files have been cached, and we're going to verify that those cached files can be used in project B, but that them still existing locally for project A shouldn't affect project B.
There was a problem hiding this comment.
It's a sanity check, just to ensure that they aren't affecting project B.
A project's build directory can be reassigned to something other than
<the project>/build. This would typically be done via some build logic that's checked in to source control and applied to any machine that builds the code. This would usually mean that all machines' build directories have the same path relative to the project root.It's possible to build directory to be re-mapped in other ways, that result in a different relative path. When this happens, the paths for source/generated files must be cached as their paths relative to the build directory, instead of the project.