| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
Action#getInputsWhenSkippingInputDiscovery().
This has the side effect of always allowing new inputs to be discovered when Action#discoversInputs() return true, but since those actions are very few and have mostly to do with C++, I think it's an acceptable tradeoff for th ecode being that much simpler.
--
PiperOrigin-RevId: 146098150
MOS_MIGRATED_REVID=146098150
|
|
|
|
|
|
|
|
|
|
| |
--android_resource_shrinking and --experimental_android_resource_shrinking as separate flags that affect the same behavior, instead of utilizing the 'oldName' feature of Options.
RELNOTES:
--
PiperOrigin-RevId: 146024304
MOS_MIGRATED_REVID=146024304
|
|
|
|
|
|
|
|
| |
--apple_crosstool_transition), the APPLE_CROSSTOOL distinguisher does not modify output directory.
--
PiperOrigin-RevId: 145999133
MOS_MIGRATED_REVID=145999133
|
|
|
|
|
|
|
|
| |
Skylark.
--
PiperOrigin-RevId: 145836240
MOS_MIGRATED_REVID=145836240
|
|
|
|
|
|
|
|
| |
objc_bundle_library rule
--
PiperOrigin-RevId: 145834899
MOS_MIGRATED_REVID=145834899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ActionSpawn/SpawnAction now deal exclusively in RunfilesSuppliers, manifests
maps are no more.
There is some lingering awkwardness, in particular:
- Manifests still need to be tracked in some places, we can work out if this is
still necessary on a case by case basis.
- Skylark makes actions' runfiles available via 'resolve_command' where they are
consumed by 'action'. I've updated the documentation, though the name isn't
entirely accurate anymore. That being said these interfaces _are_ marked as
experimental, so we _should_ be able to be flexible here.
Overall, I think the benefits consolidating runfiles into suppliers, from both
code cleanliness and performance perspectives (no longer needing to parse
manifests), outweights the awkwardnesses.
RELNOTES: resolve_command/action's input_manifest return/parameter is now list
--
PiperOrigin-RevId: 145817429
MOS_MIGRATED_REVID=145817429
|
|
|
|
|
|
|
|
| |
internal Google code.
--
PiperOrigin-RevId: 145795255
MOS_MIGRATED_REVID=145795255
|
|
|
|
|
|
|
|
| |
bundle, not the top level)
--
PiperOrigin-RevId: 145795138
MOS_MIGRATED_REVID=145795138
|
|
|
|
|
|
|
|
| |
They differed only in reporting action state and the way they reported "no include scanning happened" so there was no reason to have both of them around.
--
PiperOrigin-RevId: 145773972
MOS_MIGRATED_REVID=145773972
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145744124
MOS_MIGRATED_REVID=145744124
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flag, the headers of a target are compiled into a C++ module instead of being
parsed as their own translation unit. The module otherwise remains unused.
This way, parse_headers can be used to get a codebase ready for C++ modules.
parse_headers currently already gets close, but there are still ways in which a
header can be modules-incompatible although it parses fine.
--
PiperOrigin-RevId: 145729231
MOS_MIGRATED_REVID=145729231
|
|
|
|
|
|
|
|
|
|
| |
* Bitcode symbol maps allow Apple to provide a new dSYM output when they recompile bitcode on the App Store. This makes it possible to debug apps build with embedded bitcode.
* The new debug outputs provider makes it easy (and correct) for other rules to post-process (package, analyze, upload) dSYM and Bitcode artifacts.
--
PiperOrigin-RevId: 145720293
MOS_MIGRATED_REVID=145720293
|
|
|
|
|
|
|
|
| |
but is no longer used anywhere.
--
PiperOrigin-RevId: 145716681
MOS_MIGRATED_REVID=145716681
|
|
|
|
|
|
|
|
|
|
| |
added as inputs to dependant compile actions. This puts
experimental_objc_library in line with the behavior of objc_library, and
allows targets that specific "-fmodules" to continue to build.
--
PiperOrigin-RevId: 145714898
MOS_MIGRATED_REVID=145714898
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145701736
MOS_MIGRATED_REVID=145701736
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145688972
MOS_MIGRATED_REVID=145688972
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145686107
MOS_MIGRATED_REVID=145686107
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were adding a dependency to the rule itself, however the repository
itself can depends on further dependencies (environment, template files, ...) with
Skylark repositories. Not invalidating when those change was causing weird invalidation
issues that were shown with the invalidation on environment (basically a refetch of
the repository on environment invalidation would not cause an invalidation of the
corresponding package, the next call would not have invalidation of the repository
but would see the change in the build files...).
--
Change-Id: I8945d9885e6390734ba02ccc6c3c6ca639fcec35
Reviewed-on: https://cr.bazel.build/8137
PiperOrigin-RevId: 145675258
MOS_MIGRATED_REVID=145675258
|
|
|
|
|
|
|
|
| |
RELNOTES: Android resource shrinking is now available for android_binary rules. To enable, set the attribute 'shrink_resources = 1'. See https://bazel.build/versions/master/docs/be/android.html#android_binary.shrink_resources.
--
PiperOrigin-RevId: 145674372
MOS_MIGRATED_REVID=145674372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My assumption in commit 4cb32a994308e1b4921471e32a02c49d8ceffb84 was that lto-indexing action doesn't expand
linking features. This was wrong, and lto-indexing was broken since then as
-Wl,@thinlto_param_file was added to the command line.
This cl changes the situation by actually exposing 2 different build variables,
thinlto_indexing_param_file for lto-indexing actions, and thinlto_param_file
for normal linking actions.
--
PiperOrigin-RevId: 145669124
MOS_MIGRATED_REVID=145669124
|
|
|
|
|
|
|
|
| |
information available in the xcode config
--
PiperOrigin-RevId: 145597372
MOS_MIGRATED_REVID=145597372
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145569440
MOS_MIGRATED_REVID=145569440
|
|
|
|
|
|
|
|
| |
Fixes #2372.
--
PiperOrigin-RevId: 145539067
MOS_MIGRATED_REVID=145539067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Change is abandoned because it's a wrong solution
See https://github.com/bazelbuild/bazel/issues/2242
*** Original change description ***
java_binary now supports long classpath that exceeds command line argment length limit
When classpath length exceeds the command line length limit, we create
an empty classpath jar whose manifest contaning the whole classpath
value.
See: https://github.com/bazelbuild/bazel/issues/2242
Fixed: https://github.com/bazelbuild/bazel/issues/1780
--
PiperOrigin-RevId: 145534282
MOS_MIGRATED_REVID=145534282
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
length limit
When classpath length exceeds the command line length limit, we create
an empty classpath jar whose manifest contaning the whole classpath
value.
See: https://github.com/bazelbuild/bazel/issues/2242
Fixed: https://github.com/bazelbuild/bazel/issues/1780
--
Change-Id: Id6dd503c17f7f17e4a4c37fa01da24e2a1ea2155
Reviewed-on: https://cr.bazel.build/8353
PiperOrigin-RevId: 145521892
MOS_MIGRATED_REVID=145521892
|
|
|
|
|
|
|
|
| |
The tool will be used to construct resources jars separately from JavaBuilder.
--
PiperOrigin-RevId: 145511455
MOS_MIGRATED_REVID=145511455
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145495392
MOS_MIGRATED_REVID=145495392
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
transition at the top level for the expanded set of apple rule classes
--
PiperOrigin-RevId: 145421255
MOS_MIGRATED_REVID=145421255
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Also some apple binary test cleanup along the way.
--
PiperOrigin-RevId: 145123804
MOS_MIGRATED_REVID=145123804
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145122327
MOS_MIGRATED_REVID=145122327
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145119990
MOS_MIGRATED_REVID=145119990
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145091484
MOS_MIGRATED_REVID=145091484
|
|
|
|
|
|
|
|
| |
ExecutionInfoProvider.
--
PiperOrigin-RevId: 145084927
MOS_MIGRATED_REVID=145084927
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not intended to be a user-visible semantic change, aside from error messages.
This is to help avoid unintentional flattening of depsets, and to narrow down the number of call sites where this can occur, to help us print warning/deprecation messages.
EvalUtils#toIterable will now return an ImmutableList in place of SkylarkNestedSet. This should be ok since the caller shouldn't be relying on the result being a Skylark-safe type. Code that takes Iterable because it accepts either a list or set, can instead be changed to take Object and use EvalUtils#toIterableStrict for validation.
Note that NestedSet still implements Iterable, so native code can still easily and accidentally flatten sets.
--
PiperOrigin-RevId: 145044023
MOS_MIGRATED_REVID=145044023
|