bazel: bazel fails if workspace is not on C:
Hi,
I’m trying to build master (a18add1613574a15c81f60bde847c5d7b2bedcb5) following the instruction provided and I’m getting the error below. The path to my java jdk is correct and the folder does indeed exist. Furthermore, I can see that the first part of the compile script calls javac
from that directory without any issue.
I’m willing to try and debug this out if someone is willing to provide me with some guidance.
Thanks!
$ ./compile.sh
INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO: ./compile.sh compile /path/to/bazel
🍃 Building Bazel from scratch......
🍃 Building Bazel with Bazel.
.WARNING: C:/tools/msys64/tmp/bazel.jR1zd19q/out/external/bazel_tools/WORKSPACE:1: Workspace name in C:/tools/msys64/tmp/bazel.jR1zd19q/out/external/bazel_tools/WORKSPACE (@io_bazel) does not match the name given in the repository's definition (@bazel_tools); this will cause a build error in future versions.
ERROR: no such package '@local_jdk//': com.google.devtools.build.lib.skyframe.InconsistentFilesystemException: Inconsistent filesystem operations. C:/Program Files/Java/jdk1.8.0_73 is no longer an existing directory. Did you delete it during the build? The results of the build are not guaranteed to be correct. You should probably run 'blaze clean' and investigate the filesystem inconsistency (likely due to filesytem updates concurrent with the build).
ERROR: no such package '@local_jdk//': com.google.devtools.build.lib.skyframe.InconsistentFilesystemException: Inconsistent filesystem operations. C:/Program Files/Java/jdk1.8.0_73 is no longer an existing directory. Did you delete it during the build? The results of the build are not guaranteed to be correct. You should probably run 'blaze clean' and investigate the filesystem inconsistency (likely due to filesytem updates concurrent with the build).
INFO: Elapsed time: 1.048s
Building output/bazel
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 48 (36 by maintainers)
Commits related to this issue
- VFS: implement a Windows-specific Path subclass The new subclass WindowsFileSystem.WindowsPath is aware of Windows drives. This change: - introduces a new factory for Path objects so FileSystems c... — committed to bazelbuild/bazel by laszlocsomor 8 years ago
- VFS, WindowsFileSystem: fix UNIX_ROOT retrieval Executing bash.exe directly instead of through cmd.exe doesn't seem to work. This change fixes that problem. Fixes https://github.com/bazelbuild/bazel... — committed to bazelbuild/bazel by laszlocsomor 8 years ago
- Rollback of commit 8bb4299b28de14eed9d3b57bcaeb9350c81c7db3. *** Reason for rollback *** Suspected root cause for Windows bootstrap on Bazel CI breakage: java.lang.NullPointerException at com.goog... — committed to bazelbuild/bazel by philwo 8 years ago
- Rollback of commit 8bb4299b28de14eed9d3b57bcaeb9350c81c7db3. *** Reason for rollback *** Suspected root cause for Windows bootstrap on Bazel CI breakage: java.lang.NullPointerExcept... — committed to luca-digrazia/DatasetCommitsDiffSearch by deleted user 2 years ago
- VFS, WindowsFileSystem: fix UNIX_ROOT retrieval Executing bash.exe directly instead of through cmd.exe doesn't seem to work. This change fixes that problem. Fixes https://github.... — committed to luca-digrazia/DatasetCommitsDiffSearch by deleted user 2 years ago
Out for review. If all goes well, we can push the fix to GH today or tomorrow.
For later reference, I’m able to work around this by
s:\whatever\here
)c:
mklink /j c:\src\s-drive s:\whatever\here
I have a fix for this, stay tuned.
Bumping priority again because this is a serious blow on usability.