| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
This makes it clearer that the path fragments in question are relative *to the root*. Confusingly, when the root is absolute, the root relative fragment is also absolute. This makes it a tiny bit clearer that the path fragment may be absolute.
PiperOrigin-RevId: 182544893
|
|
|
|
|
|
|
|
|
|
|
| |
This class represents a root (such as a package path or an output root) used for file lookups and artifacts. It is meant to be as opaque as possible in order to hide the user's environment from sky keys and sky functions.
Roots are used by RootedPaths and ArtifactRoots.
This CL attempts to make the minimum number of modifications necessary to change RootedPath and ArtifactRoot to use these fields. Deprecated methods and invasive accessors are permitted to minimise the risk of any observable changes.
RELNOTES: None
PiperOrigin-RevId: 182271759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #4322, #4306.
*** Reason for rollback ***
Introduces a deadlock (see https://github.com/bazelbuild/bazel/issues/4322)
*** Original change description ***
Make FileSystem operate on LocalPath instead of Path.
PiperOrigin-RevId: 179549866
|
|
|
|
| |
PiperOrigin-RevId: 179082062
|
|
|
|
|
|
|
|
| |
system.
This is the only place that should actually need it.
PiperOrigin-RevId: 179054861
|
|
|
|
|
|
|
|
| |
This path type is a local file path as a wrapper around a string. It works much the same as java.io.File, but without its file operations.
For the most part, FilePath shouldn't add much overhead compared to using plain strings. Strings do get normalised on the way in, but no extra objects are allocated unless the path actually needs normalisation.
PiperOrigin-RevId: 178798497
|
|
|
|
|
|
|
|
|
|
|
| |
Quote empty args in the command argument vector
otherwise the command's executable would not
recognize them as arguments.
Fixes https://github.com/bazelbuild/bazel/issues/3973
Change-Id: Iccfb59e75c748247c8df7d52fb8cf4227eae6fa7
PiperOrigin-RevId: 175672201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit:
- introduce the MakeErrorMessage function, which
creates a structured error message with file
and line information of the error's origin
- update all error messages in the Windows JNI
library
- simplify GetLastErrorMessage to just convert an
error code to string, without prepending a cause
Change-Id: Ia8162bfdaee37d4b7ccb3a46d6c8a861b0a1bd94
PiperOrigin-RevId: 173402968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two close operations were added to work around #1708, but caused #2675.
We found the root cause of the hanging problem in #1708 is a race
condition when creating Windows processes:
When Bazel trys to create two processes, one for a local command
execution, one for starting the worker process. The worker process
might accidentally inherits handles opened when creating the local
command process, and it holds those handles as long as it lives.
Therefore, ReadFile function hangs when handles for the write end of
stdout/stderr pipes are released by the worker.
The solution is to make Bazel native createProcess JNI function
explicitly inheirts handles as needed, and use this function to start
worker process.
Related: http://support.microsoft.com/kb/315939
Fixed https://github.com/bazelbuild/bazel/issues/2675
Change-Id: I1c9b1ac3c9383ed2fd28ea92f528f19649693275
PiperOrigin-RevId: 173244832
|
|
|
|
|
|
| |
RELNOTES: The Build Event Protocol's File.uri field is now properly
encoded according to RFC2396.
PiperOrigin-RevId: 168674865
|
|
|
|
|
|
|
|
|
| |
Split collect, concurrent, vfs, windows into package-level BUILD files.
Move clock classes out of "util", into their own Java package.
Move CompactHashSet into its own Java package to break a dependency cycle.
Give nestedset and inmemoryfs their own package-level BUILD files.
PiperOrigin-RevId: 167702127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the Java JNI sources to a separate package:
c.g.devtools.build.lib.windows.jni and
c.g.devtools.build.lib.windows.runfiles.
Make the native method declarations private,
create public wrapper methods for them that ensure
that the JNI library is loaded.
Split the C++ JNI source processes.cc into two
parts (processes-jni.cc and file-jni.cc), extract
common functionality to jni-util.{h,cc}.
This change preparse the code for Android rule
support on Windows, specifically it lets the
Android BusyBox use the file JNI library so it can
create junctions on Windows to work around long
path issues when calling external tools.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I7f1a746d73f822ae419d11b893a91f4eb45d64da
PiperOrigin-RevId: 160643355
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 157685150
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 157576492
|
|
|
|
|
|
|
|
|
| |
catch.
IntelliJ's "replace structurally" command was surprisingly useful.
RELNOTES: None.
PiperOrigin-RevId: 157463734
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 152400979
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PathFragment's `equals`, `hashCode`, `compareTo`,
`startsWith`, `endsWith`, and `relativeTo` are now
aware of case-insensitivity when running on
Windows.
This approach is better than
https://bazel-review.googlesource.com/c/9124/
because it preserves path casing, which is
important when computing action output paths.
This change contains two additional bugfixes:
- `compareTo` now takes `driveLetter` into account
- the `InMemoryFileSystem` in `PathWindowsTest` is
not case-insensitive
Fixes https://github.com/bazelbuild/bazel/issues/2613
--
Change-Id: I1a4250a373fff03fa02a6d8360457450b47a42a8
Reviewed-on: https://cr.bazel.build/9126
PiperOrigin-RevId: 149106930
MOS_MIGRATED_REVID=149106930
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 148749485
MOS_MIGRATED_REVID=148749485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the new CreateJunction in the Windows JNI code
every time we need to create junctions. This means
updating WindowsFileOperations and related tests.
Add test for WindowsFileSystem.createSymbolicLink.
See https://github.com/bazelbuild/bazel/issues/2238
--
Change-Id: I5827e2e70e8e147f5f102fabf95fa9a148b3bcdc
Reviewed-on: https://cr.bazel.build/8896
PiperOrigin-RevId: 147598107
MOS_MIGRATED_REVID=147598107
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In almost every place we compared paths against
MAX_PATH, we had it wrong. MAX_PATH is the
null-terminated maximum length, so paths exactly
MAX_PATH long (not counting the null-terminator)
were incorrectly considered short.
Also fix the error message in the MSVC python
wrapper, because it reported an incorrect path
length limit in the warning message.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 146762382
MOS_MIGRATED_REVID=146762382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When spawning a new process with CreateProcessA,
convert argv0 to a 8dot3 style short path so we
can support longer paths than MAX_PATH. This is
the same approach we did in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 144613589
MOS_MIGRATED_REVID=144613589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a separate argument to nativeCreateProcess for
argv[0] specifically, and another for the rest of
the args.
In a subsequent change I'll add code to compute
the 8dot3 style short name of the argv[0] so we
can use longer paths for executables in
CreateProcessA than we normally could. This is the
same approach as used in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 144311562
MOS_MIGRATED_REVID=144311562
|
|
|
|
|
|
|
|
|
|
| |
WindowsJniLoader.loadJniForTesting is just a
special case of what WindowsJniLoader.loadJni
already does, so we can just use the latter.
--
PiperOrigin-RevId: 144224388
MOS_MIGRATED_REVID=144224388
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the behavior of the UnixJniLoader. In order to do that, this
change also moved the runfiles support on Windows in its own library
that the WindowsJniLoader can use to load the JNI library from tests.
Also add the JNI library on Windows to all test that use the JNI library
on Unix.
Fixes #2300.
--
Change-Id: I2eb9207c3aa310d95912a48f64f676957c47cd34
Reviewed-on: https://cr.bazel.build/8045
PiperOrigin-RevId: 143114397
MOS_MIGRATED_REVID=143114397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a JNI method that can resolve 8dot3
style paths. This is necessary because we need to
be able to compare 8dot3 style paths and long
paths [1], and because implementing this correctly
in Java seems to be impossible [2].
This change also adds tests for the JNI isJunction
implementation.
See https://github.com/bazelbuild/bazel/issues/2101
[1] https://github.com/bazelbuild/bazel/issues/2145
[2] https://github.com/bazelbuild/bazel/issues/2145#issuecomment-266766716
--
PiperOrigin-RevId: 142123750
MOS_MIGRATED_REVID=142123750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change:
- renames windows_error_handling.* to
windows_util.*
- moves most stuff except for the JNI method
implementations into the new windows_util
namespace
- implements a jstring to wchar string converter
- uses GetFileAttributesW in
windows_file_operations.cc
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 141187291
MOS_MIGRATED_REVID=141187291
|
|
|
|
|
|
|
| |
Fixes #1755.
--
MOS_MIGRATED_REVID=132861187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also add tests for WindowsFileSystem and some for
WindowsFileOperations, so we test both the
JNI-based and Java-native isJunction function, as
well as handling of dangling symlinks/junctions.
Having a Java-native version of this method means
we don't need to use windows_jni.dll for any tests
or for bootstrapping.
This change could help with
https://github.com/bazelbuild/bazel/issues/1735
--
MOS_MIGRATED_REVID=132556440
|
|
|
|
|
|
|
|
|
| |
Move more logic from FilesFileOperationsTest into
WindowsTestUtil, and further separate test files
in the BUILD file.
--
MOS_MIGRATED_REVID=132417714
|
|
|
|
|
|
|
|
|
|
|
|
| |
Additionally:
- clean up the corresponding BUILD file a bit
- add a comment to Path
A subsequent change will add tests for
WindowsFileSystem, then fix a bug there.
--
MOS_MIGRATED_REVID=132408212
|
|
|
|
|
|
|
| |
WindowsFileSystem.java does not yet use it.
--
MOS_MIGRATED_REVID=132043739
|
|
|
|
|
|
|
| |
Makes #1664 much less acute.
--
MOS_MIGRATED_REVID=130750731
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weren't actually running the test:
- Call TerminateProcess() only if the process handle is still open
- Update the tests so that they expect a return value of 0 when reading a stream from a non-existent process
Fixes #1538 .
--
Change-Id: I4de28abbba2e2e89f285d7b8fb75bcd9af345f14
Reviewed-on: https://bazel-review.googlesource.com/4100
MOS_MIGRATED_REVID=127935621
|
|
|
|
|
|
|
|
|
|
|
| |
1. Return EOF for streams representing Windows process pipes.
2. Fix the timing of process.close()
3. Un-synchronized reading of stderr and stdout.
--
Change-Id: Iec98f45db9984be2c2b066962801cbd3ca60da3f
Reviewed-on: https://bazel-review.googlesource.com/#/c/4000/
MOS_MIGRATED_REVID=126910063
|
|
|
|
|
|
|
| |
--
Change-Id: Ic474eff981328b0a467606a01f88d72c26dfff74
Reviewed-on: https://bazel-review.googlesource.com/#/c/3965
MOS_MIGRATED_REVID=126636071
|
|
|
|
|
|
|
|
|
|
|
| |
to Windows process management.
With this change, Bazel can build itself using native Windows process management and Ctrl-C works in server mode as expected. Yay!
Flipping the flag will come in a separate change that's easy to roll back if need be.
--
MOS_MIGRATED_REVID=126408264
|
|
sane Java API for now)
--
MOS_MIGRATED_REVID=126306559
|