fix relative path calculation #1143
Conversation
| val gradleRunner = GradleRunner.create().withProjectDir(project.root) | ||
|
|
||
| File(project.root, "workload/build.gradle.kts") | ||
| .appendText("project.buildDir = File(\"D:/build/\")") |
There was a problem hiding this comment.
note that it does seem like there is only one C drive on github windows runners, therefore this test might not be testable on github runners.
neetopia
force-pushed
the
build-dir
branch
2 times, most recently
from
b89e062
to
a68d2a7
Compare
| @@ -154,18 +155,25 @@ class CodeGeneratorImpl( | |||
| associate(sources, file) | |||
| } | |||
|
|
|||
| private val File.relativeFile: File | |||
| get() = | |||
| if (this.startsWith(buildDir)) | |||
There was a problem hiding this comment.
I found the reason this fails on Windows.
Windows uses counter slash for directory separator, but in Java API it seems to be intepreting the path as URI, which uses normal slash as directory separator, and this causes lots of issues that will break simple string check.
One workaround is to manually replace counter slash with normal slash when doing check, but counter slash is a valid file name character on unix, uncommon but valid, which messes things up again...
Maybe also put an OS check before checking the strings, but that looks just too bad as a code to me.
neetopia
force-pushed
the
build-dir
branch
2 times, most recently
from
9ff87e5
to
063a0fb
Compare
The source-to-output map and path converter for lookup tracker needs to be multiplexed as well.
My concern on the
startsWithcheck is true, we have to fallback to try catch for better accuracy.Open to discussion on better approach other than try catch, hence left one place unchanged, should change to try catch if we deciced to proceed with this approach.
fixes #1079