| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the FileSystem class to include the hash function as an
instance field. This allows us to have a different hash function
per FileSystem and removes technical debt, as currently that's
somewhat accomplished by a horrible hack that has a static method
to set the hash function for all FileSystem instances.
The FileSystem's default hash function remains MD5.
RELNOTES: None
PiperOrigin-RevId: 177479772
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own.
This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually.
PiperOrigin-RevId: 175033526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This works better with UnionFileSystem, as (eg.) different mapped file systems might not agree on whether they are read-only.
No actual code changes have been made that actually uses this argument, so this should be a behaviour no-op.
PiperOrigin-RevId: 172782759
|
|
|
|
|
|
|
|
|
|
|
| |
Also move the implementation of FutureCommandResult to a top-level class.
This is in preparation for significantly simplifying the shell library. The
plan is to remove the Subprocess abstraction, and have lower-level
implementations implement the much simpler FutureCommandResult interface
instead.
PiperOrigin-RevId: 167844736
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 164827022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Important: the simplified API now defaults to forwarding interrupts to
subprocesses. I did audit all the call sites, and I think this is a safe change
to make.
- Properly support timeouts with all implementations
- Simplify the API
- only provide two flavours of blocking calls, which require no input and
forward interrupts; this is the most common usage
- provide a number of async calls, which optionally takes input, and a flag
whether to forward interrupts
- only support input streams, no byte arrays or other 'convenience features'
that are rarely needed and unnecessarily increase the surface area
- use java.time.Duration to specify timeout; for consistency, interpret a
timeout of <= 0 as no timeout (i.e., including rather than excluding 0)
- KillableObserver and subclasses are no longer part of the public API, but
still used to implement timeouts if the Subprocess.Factory does not support
them
- Update the documentation for Command
- Update all callers; most callers now use the simplified API
PiperOrigin-RevId: 164716782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a data-dependency on the windows_jni.dll from
the BusyBox in BUILD.tools, so the BusyBox in
@build_tools// can actually find it at runtime.
Also update the script that builds the .dll so
that it works if the source files have an
"external/bazel_tools/" prefix.
Related to https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I005e9d2c00253a59d2cd5cc9f3a93528dc4d2e9e
PiperOrigin-RevId: 163691320
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce the JunctionCreator classes that the
Android BusyBox can use to work around path length
limitations on Windows.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: Ia5ee39f0635dcc2690ffb1755dc56d21e7bc7536
PiperOrigin-RevId: 161378422
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The script more logically belongs in
src/main/native/windows than in src/main/native.
Also move the //src/main/native:windows_jni rule
into //src/main/native/windows:windows_jni, so the
logic of building the JNI library is fully
contained in that package.
Change-Id: I96e19003932cc0ddc5af3471b0b31a1aec09b8fa
PiperOrigin-RevId: 160876594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Bazel client will pass the
--host_jvm_args=-Dbazel.windows_unix_root=<path>
flag to the server (computed from $BAZEL_SH), and
the server will no longer shell out to cygpath to
compute this value.
Fixes https://github.com/bazelbuild/bazel/issues/2983
Change-Id: Iacc2e2eb70eacafdf7bbcad68d375ba9eadc6ee1
PiperOrigin-RevId: 158830675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Unix system, `ln -s foo bar` will create an dangling symlink bar -> foo
even foo doesn't exist. The current implementation of createSymbolicLink for
Windows fails in this situtation. And this lead to #2474.
In this change, we create a dangling junction when the target doesn't exist
which mimics the behavior on Unix.
Fixed https://github.com/bazelbuild/bazel/issues/2474
Change-Id: I442ca3e2fb20b76c9b5bbfee903299fe51481f43
PiperOrigin-RevId: 157694631
|
|
|
|
|
|
|
|
|
|
|
|
| |
'create' method.
This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment).
This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations.
RELNOTES: None
PiperOrigin-RevId: 152145768
|
|
|
|
|
|
|
|
| |
allocating a garbage TranslatedPath object.
RELNOTES: None
PiperOrigin-RevId: 152130170
|
|
|
|
|
|
| |
--
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145473478
MOS_MIGRATED_REVID=145473478
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TL;DR: resolve "C:/progra~1" style paths, don't
cache failed resolutions in the parent's
Path.children
When creating WindowsPath objects, resolve the
"C:/progra~1" style paths to "C:/program files".
This enables us to correctly compare paths on
Windows. Without this canonicalization we
incorrectly determine "C:/progra~1" and
"C:/program files" to be different when they are
actually the same.
We only attempt to resolve such paths if the name
looks like it's an abbreviated path.
If resolution fails, probably due to the path not
existing, then we don't cache this Path object in
the parent's `children` list. This avoids stale
cache entries in case the path springs into
existence later in the server's lifetime.
Fixes https://github.com/bazelbuild/bazel/issues/2145
We also need to rectify https://github.com/bazelbuild/bazel/issues/2173
--
PiperOrigin-RevId: 143442134
MOS_MIGRATED_REVID=143442134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 142670226
MOS_MIGRATED_REVID=142670226
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Fixed #1732
RELNOTES:
--
MOS_MIGRATED_REVID=132436686
|
|
|
|
|
|
|
| |
WindowsFileSystem.java does not yet use it.
--
MOS_MIGRATED_REVID=132043739
|
|
|
|
|
|
|
|
|
| |
WindowsProcesses.ensureJni() was duplicating the work of
WindowsJniLoader.loadJni(); this change removes the former and
replaces the only call site with the latter.
--
MOS_MIGRATED_REVID=131806917
|
|
|
|
|
|
|
| |
Makes #1664 much less acute.
--
MOS_MIGRATED_REVID=130750731
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
This is apparently required by some versions MSVCRT.DLL including the one used in the CL.EXE we happen to be using for testing.
This was learned by reading the source code of OpenJDK.
Fixes #1480.
--
MOS_MIGRATED_REVID=126786461
|
|
|
|
|
|
|
|
|
| |
Subprocesses now get killed if the Bazel server itself is killed and so do their subprocesses.
Also implemented Subprocess#close() so that we get a little more control over when the native structures are cleaned up.
--
MOS_MIGRATED_REVID=126628000
|
|
|
|
|
|
|
| |
We should really do something about the mess that is loading our JNI libraries -- io.bazel.EnableJNI is mentioned eight times in the code in various diverse contexts. This change is not the right place to do it, though.
--
MOS_MIGRATED_REVID=126570481
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
This is the first actual use of Windows JNI!
Also a cleanup of ProcessUtils. Injecting a mock implementation was never used.
--
MOS_MIGRATED_REVID=126068832
|
|
Tested by hacking in a call to a JNI method into BatchMain.java .
--
Change-Id: I77b0731fa6b81f8cbc80cf2a31d427764fad6ad1
Reviewed-on: https://bazel-review.googlesource.com/#/c/3908/
MOS_MIGRATED_REVID=125955521
|