| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145473478
MOS_MIGRATED_REVID=145473478
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145473123
MOS_MIGRATED_REVID=145473123
|
|
|
|
|
|
|
|
| |
performed in order to expose it in build summary output.
--
PiperOrigin-RevId: 145457357
MOS_MIGRATED_REVID=145457357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
After discussing with thomaswk@, we've decided not to put these in the android_sdk.
*** Original change description ***
Add attributes to android_sdk rule so that they will be available for open sourcing android_device.
--
PiperOrigin-RevId: 145444443
MOS_MIGRATED_REVID=145444443
|
|
|
|
|
|
|
|
| |
sourcing android_device.
--
PiperOrigin-RevId: 145429610
MOS_MIGRATED_REVID=145429610
|
|
|
|
|
|
|
|
|
|
|
| |
Now Bazel JavaBuilder can specifiy a file as the manifest file, before
this it just creates the manifest file on the fly.
--
Change-Id: I515d63a008e2c9e9113c56d3646b8bc78b76b3a7
Reviewed-on: https://cr.bazel.build/8352
PiperOrigin-RevId: 145428635
MOS_MIGRATED_REVID=145428635
|
|
|
|
|
|
|
|
| |
transition at the top level for the expanded set of apple rule classes
--
PiperOrigin-RevId: 145421255
MOS_MIGRATED_REVID=145421255
|
|
|
|
|
|
|
|
| |
that they are running in hjar compilation
--
PiperOrigin-RevId: 145413255
MOS_MIGRATED_REVID=145413255
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel tests on Windows: see https://github.com/bazelbuild/bazel/issues/2408
--
PiperOrigin-RevId: 145411907
MOS_MIGRATED_REVID=145411907
|
|
|
|
|
|
|
|
|
| |
Remove (output != null) check which is always true and cleanup dependent
conditionals.
--
PiperOrigin-RevId: 145409269
MOS_MIGRATED_REVID=145409269
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of unifying the test strategies; here, I'm working towards
sharing the test environment setup.
This change moves code from previously closed source code into the open
source parts. The internal change is not visible, making this look like an
addition rather than a move..
The next change hooks this up to Bazel. I did this in order to reduce the
size of the change to make it easier to debug, review, and so that it's
smaller in case we have to roll it back. Unfortunately, that requires
duplicating some of the code in StandaloneTestStrategy until the next change
lands.
--
PiperOrigin-RevId: 145387109
MOS_MIGRATED_REVID=145387109
|
|
|
|
|
|
|
|
| |
brings it in line with the behavior in objc_library.
--
PiperOrigin-RevId: 145330154
MOS_MIGRATED_REVID=145330154
|
|
|
|
|
|
|
|
|
|
| |
Completion failures are usually caught and printed at the top-level, but
if they occur inside an Error Prone check they get wrapped and reported
as error diagnostics.
--
PiperOrigin-RevId: 145322258
MOS_MIGRATED_REVID=145322258
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145322062
MOS_MIGRATED_REVID=145322062
|
|
|
|
|
|
|
|
|
| |
This is required for compatibility with existing runtimes specified
as filegroups.
--
PiperOrigin-RevId: 145314598
MOS_MIGRATED_REVID=145314598
|
|
|
|
|
|
|
|
| |
finding actions based on intermediate artifacts.
--
PiperOrigin-RevId: 145303065
MOS_MIGRATED_REVID=145303065
|
|
|
|
|
|
|
|
| |
--
Change-Id: I0aa54455ba4a17ad42a22c31a04f6417544ea6df
Reviewed-on: https://cr.bazel.build/8431
PiperOrigin-RevId: 145293680
MOS_MIGRATED_REVID=145293680
|
|
|
|
|
|
|
|
| |
One's unused, the other is ok as protected.
--
PiperOrigin-RevId: 145291062
MOS_MIGRATED_REVID=145291062
|
|
|
|
|
|
|
|
|
|
| |
that provider to retrieve the executable binary to act as the bundle_loader.
Also passes the bundle loader's ObjcProvider and ObjcProtoProviders to the dylib deduping mechanism to avoid dual linking of symbols into the tests.
--
PiperOrigin-RevId: 145284598
MOS_MIGRATED_REVID=145284598
|
|
|
|
|
|
|
|
| |
(as oposed to proto_library targets) would result in a crash.
--
PiperOrigin-RevId: 145283582
MOS_MIGRATED_REVID=145283582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel-Install-Trigger on CI.
*** Original change description ***
Bazel client, Windows: impl. ForEachDirectoryEntry
Implement ForEachDirectoryEntry on Windows using
FindFirstFileW / FindNextFileW.
Supports long paths and traversing junctions.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 145282158
MOS_MIGRATED_REVID=145282158
|
|
|
|
|
|
|
|
|
|
| |
the scope.
This seems to only have been a problem when the error was in an unselect path, as the query would have failed earlier otherwise.
--
PiperOrigin-RevId: 145282112
MOS_MIGRATED_REVID=145282112
|
|
|
|
|
|
|
|
| |
Also refactoring JavaProvider to use the Builder pattern, given that it is going to encapsulate a fair number of other providers.
--
PiperOrigin-RevId: 145280532
MOS_MIGRATED_REVID=145280532
|
|
|
|
|
|
|
|
|
|
| |
This cl relieves us from hard-coding -l and -l: flags in Bazel. To be able to
express the behavior in CROSSTOOL, we need to know what type of library are we
dealing with.
--
PiperOrigin-RevId: 145271426
MOS_MIGRATED_REVID=145271426
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145156880
MOS_MIGRATED_REVID=145156880
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145152574
MOS_MIGRATED_REVID=145152574
|
|
|
|
|
|
|
|
|
| |
we only care about success or failure, and this avoids an internal
API use.
--
PiperOrigin-RevId: 145151690
MOS_MIGRATED_REVID=145151690
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145145109
MOS_MIGRATED_REVID=145145109
|
|
|
|
|
|
|
|
| |
Fixes bazelbuild/bazel#1342
--
PiperOrigin-RevId: 145144856
MOS_MIGRATED_REVID=145144856
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the event handler's inner handlers are removed after each query
command, caching the handler caused a subset of subsequent commands'
errors (those reported through the resolver's handler) to go unlogged.
Also fix a bug with cycle detection in DelegatingWalkableGraph.
--
PiperOrigin-RevId: 145124271
MOS_MIGRATED_REVID=145124271
|
|
|
|
|
|
|
|
| |
Also some apple binary test cleanup along the way.
--
PiperOrigin-RevId: 145123804
MOS_MIGRATED_REVID=145123804
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145122327
MOS_MIGRATED_REVID=145122327
|
|
|
|
|
|
|
|
| |
proto_library's wrt strict Java deps.
--
PiperOrigin-RevId: 145120944
MOS_MIGRATED_REVID=145120944
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145119990
MOS_MIGRATED_REVID=145119990
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145091484
MOS_MIGRATED_REVID=145091484
|
|
|
|
|
|
|
|
| |
with the internal GenRule implementation.
--
PiperOrigin-RevId: 145087704
MOS_MIGRATED_REVID=145087704
|
|
|
|
|
|
|
|
|
| |
The code has been untouched and unused for over a year (it's very likely
broken) and we have other priorities for now.
--
PiperOrigin-RevId: 145087310
MOS_MIGRATED_REVID=145087310
|
|
|
|
|
|
|
|
| |
ExecutionInfoProvider.
--
PiperOrigin-RevId: 145084927
MOS_MIGRATED_REVID=145084927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out, we couldn't run jarjar because the Java launcher script looks for the .jars in the runfiles and build-runfiles is stubbed out during bootstrapping.
The only reason why this worked at all is that sandboxing *also* doesn't work during bootstrapping but it causes the creation of symlinks that happened to be just in the right place for the Java launcher to find the .jars .
The fix is:
- Explicitly disable sandboxing during bootstrapping so that coincidences like this don't happen again
- Pass a --javabase and --host_javabase option during the bootstrap build so that we don't need any symlinks to access to JVM
- Invoke jarjar using its deploy jar instead of the launcher script.
That was fun.
--
PiperOrigin-RevId: 145083357
MOS_MIGRATED_REVID=145083357
|
|
|
|
|
|
|
|
|
| |
This functionality is never used, have never been exposed to Skylark
and is a continuous pain to maintain and test.
--
PiperOrigin-RevId: 145079832
MOS_MIGRATED_REVID=145079832
|
|
|
|
|
|
|
|
|
|
| |
Specifying both options can cause OOM on OSX.
--
Change-Id: I52daf194a8840f9e63f1d537f13152e53f8436a7
Reviewed-on: https://cr.bazel.build/8220
PiperOrigin-RevId: 145079331
MOS_MIGRATED_REVID=145079331
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When looking up the .bazelrc file in the workspace or the home directory,
construct its name using the built-in product name instead of hardcoding
the name in the WorkspaceLayout class.
This removes an additional hardcoded value and changes the code to do the
right thing based on the product name.
--
PiperOrigin-RevId: 145077783
MOS_MIGRATED_REVID=145077783
|
|
|
|
|
|
|
|
|
|
| |
This seems like an obvious cleanup, and I also want to move most of the
test-specific environment setup to TestRunnerAction, which is simpler after
this change.
--
PiperOrigin-RevId: 145076829
MOS_MIGRATED_REVID=145076829
|
|
|
|
|
|
|
|
|
|
|
| |
For example, on FreeBSD, ${PREFIX}/bin/python is a symlink
to the correct python version.
--
Change-Id: Iae79caae8d98530a6d8656b1915a8d5de9c132ea
Reviewed-on: https://cr.bazel.build/8396
PiperOrigin-RevId: 145068920
MOS_MIGRATED_REVID=145068920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Unwrapping JavaCompilationArgsProvider from JavaProvider when collecting compile time dependencies artifacts (in addition to JavaCompilationArgsProvider), so that java_library could depend on Skylark rules that return java_common.provider. (this makes java sandwich complete \o/)
* Added a new param (source_files) to java_common.compile to allow compilation of source files in addition to source jars.
* Added a new sourceFiles field to JavaLibraryHelper in order to pass them to JavaCompilationHelper.
* Added a new method (java_common.default_javac_opts) for default Java compilation.
* Added a test for a basic java sandwich.
--
PiperOrigin-RevId: 145064700
MOS_MIGRATED_REVID=145064700
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move JNI code from windows_file_operations.cc to
windows_processes.cc, so all the JNI code is now
in the latter.
This lets us expose windows_file_operations.* to
the Bazel client (via the ":windows_jni_lib"
target), so we can finally share file handling
logic between the Bazel client and the JNI
library.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 145063140
MOS_MIGRATED_REVID=145063140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extract a WinAPI call from the JNI method's body.
In a subsequent change I'll move all JNI methods
to a common location (windows_processes.cc) and
that will be the only file dealing with JNI stuff.
The rest of the windows_* sources will be exposed
in the //src/main/native:windows_jni_util library
so the Bazel client can also depend on it later.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 145062890
MOS_MIGRATED_REVID=145062890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement ForEachDirectoryEntry on Windows using
FindFirstFileW / FindNextFileW.
Supports long paths and traversing junctions.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 145062749
MOS_MIGRATED_REVID=145062749
|
|
|
|
|
|
|
|
|
|
| |
...while we have the problem with the hard-coded path to /bin/bash.
--
Change-Id: Icba0030458da42d1847fa68d6bf312195ff083f9
Reviewed-on: https://cr.bazel.build/8393
PiperOrigin-RevId: 145062669
MOS_MIGRATED_REVID=145062669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a simple refactoring, no change in
functionality.
Create a windows_file_operations.h file, declare
windows_util::IsJunctionOrDirectorySymlink there,
We will include this file in the cc_library
//src/main/native:windows_jni_lib later and use
it from the Bazel client.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 145062164
MOS_MIGRATED_REVID=145062164
|