aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules
Commit message (Collapse)AuthorAge
* C++: Remove CcLinkParamsStore parameter from CcLinkingInfo.Gravatar plf2018-06-25
| | | | | | | | | | I will remove the CcLinkParamsStore class in a separate CL. For now, make sure the API doesn't expose this class. The only Skylark use was in cc_import which is migrated in this CL. RELNOTES:none PiperOrigin-RevId: 201948058
* ToolchainContext directly implements SkylarkValue and SkylarkIndexable.Gravatar John Cater2018-06-22
| | | | | Change-Id: I355b138e143771fd826ab03951df821ea7d58ac5 PiperOrigin-RevId: 201740564
* Delete an unused methodGravatar cushon2018-06-22
| | | | PiperOrigin-RevId: 201723154
* Automated rollback of commit 28a999cff60fa5a8c9ca045ab2b202d83a0e0583.Gravatar kaipi2018-06-22
| | | | | | | | | | | | *** Reason for rollback *** see b/109887056 *** Original change description *** Stop objc_proto_library from returning the generated sources. PiperOrigin-RevId: 201709908
* Expose aspect actions from Skylark.Gravatar tomlu2018-06-22
| | | | | | | | | | | Like with providers, consumers get a merged view of all actions from the merged configured target (all other aspects + the base target). I had to rejig the aspect value / configured aspect to be symmetric with rule configured targets. I do not expect significant memory bloat from this. All lists / maps already existed, only extra fields have been added. RELNOTES: Expose aspect actions provider to Skylark. PiperOrigin-RevId: 201697923
* Audit usages of Label.getRelative and update to Label.getRelativeWithRemappingGravatar dannark2018-06-21
| | | | | RELNOTES: None PiperOrigin-RevId: 201617188
* Add binfiles to quoted include directories for C++ compilationGravatar hlopko2018-06-21
| | | | | | | | | | | | | | | The only non-deprecated way to declare new files in Skylark is using ctx.actions (https://docs.bazel.build/versions/master/skylark/lib/actions.html). And these files are created in binfiles (there is one way to generate a file in Skylark in genfiles: a rule can be tagget with 'output_to_genfiles = True' attribute, but that forces all files of all actions in the rule to be generated in genfiles. And this attribtue is deprecated). Similarly, https://github.com/bazelbuild/bazel/commit/6c2f499b21e36c59d7da5e8b2e6c9b1804a36c64 added binfiles for <> includes when using cc_library.includes attribute. RELNOTES: None. PiperOrigin-RevId: 201504199
* Extract logic from CROSSTOOL in CrosstoolInfo providerGravatar rosica2018-06-21
| | | | | | | | | CrosstoolInfo carries the necessary information from the CROSSTOOL text proto. Later on, instead from the CROSSTOOL file and the corresponding CToolchain, CrosstoolInfo will be derived from a skylark_crosstool rule implemented in Skylark. Therefore CToolchain involvement in CppConfiguration and CcToolchain creation needs to be eliminated. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 201491207
* Add a minimum_os_version flag that is platform agnostic.Gravatar Googler2018-06-20
| | | | | | | | | | | | | | This corresponds to the os version in the clang target triple, though clang does have corresponding os_version_min flags for Apple platforms. Currently, Bazel has --XX_minimum_os flags for XX values corresponding to Apple platforms. This flag is the generic version of that (and can and will be set after the Apple split transition, and will eventually be set in the Android split as well) to support various Android API level improvements for native code. PiperOrigin-RevId: 201453961
* Clean out unused proto_library enforcement code.Gravatar tomlu2018-06-20
| | | | | | | | | | | | The corresponding flags have been flipped and there should be no code in the depot that violates these rules. * Make it completely illegal for proto_library to appear in any Java/Android rule * Delete code that uses the old migration flags. * Delete tests that check that Java/Android rules *can* depend on proto_library rules when certain flags are off. * Update tests (the error messages are now slightly different) RELNOTES: None PiperOrigin-RevId: 201384236
* Don't instrument files generated by cc_proto_library for coverageGravatar Googler2018-06-20
| | | | | RELNOTES=None PiperOrigin-RevId: 201365986
* Remove genrule's special handling of the "toolchains" attribute.Gravatar jcater2018-06-20
| | | | | | The general handling should be fine for this. PiperOrigin-RevId: 201352916
* C++: Re-writes cc_import in Skylark.Gravatar plf2018-06-20
| | | | | | | I will put cc_import.bzl in Bazel in a follow up CL. RELNOTES:none PiperOrigin-RevId: 201332133
* Remove the $(JAVA_TRANSLATIONS) Make variable.Gravatar lberki2018-06-19
| | | | | | RELNOTES[INC]: The $(JAVA_TRANSLATIONS) Make variable is not supported anymore. PiperOrigin-RevId: 201278971
* Make some Android things more serializable.Gravatar janakr2018-06-19
| | | | PiperOrigin-RevId: 201228699
* Make things easier to serialize: make constants constant, tag some lambdas. ↵Gravatar janakr2018-06-19
| | | | | | Get rid of a useless tag, because the Function being tagged is a concrete class, so won't be serializable. Will deal with it in a follow-up. Implement equality for BazelInfo. PiperOrigin-RevId: 201199255
* Make variable providers coming from the toolchains attribute shouldn't beGravatar jcater2018-06-19
| | | | | | | checked for restricted_to and compatible_with constraints, because they are part of the execution, not providing new dependencies. PiperOrigin-RevId: 201196891
* Make some Apple objects more serializable: tag constants as constant, tag ↵Gravatar janakr2018-06-19
| | | | | | lambdas as Serializable. PiperOrigin-RevId: 201191461
* C++: Refactors PyWrapCc to make it easier to migrate to SkylarkGravatar plf2018-06-19
| | | | | | | | | Rolls forward https://github.com/bazelbuild/bazel/commit/c720152ec1936a537c9519d522d3cb41d19cff77. This CL includes testing to make sure that linker parameters coming from every possible provider in Python rules is propagated. RELNOTES:none PiperOrigin-RevId: 201160720
* Add fields to CcToolchainFeatures.Feature and ↵Gravatar rosica2018-06-19
| | | | | | | | | | | CcToolchainFeatures.ActionConfig that are needed for FeatureConfiguration creation In the future CcToolchainFeatures will not be created from a CToolchain but from a CrosstoolInfo provider that will encapsule all relevant information from the CROSSTOOL. Feature and ActionConfig classes need to carry all the information that is currently obtained from CToolchain. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 201147336
* Remove support for --discard_actions_after_execution.Gravatar tomlu2018-06-18
| | | | | | | The memory savings from this flag are not worth the complexity, and it interferes with action restarting. RELNOTES: Remove support for --discard_actions_after_execution. PiperOrigin-RevId: 201077905
* Automated rollback of commit c720152ec1936a537c9519d522d3cb41d19cff77.Gravatar janakr2018-06-18
| | | | | | | | | | | | | | | | | *** Reason for rollback *** See linked bug. *** Original change description *** C++: Refactors PyWrapCc to make it easier to migrate to Skylark Rolling forward https://github.com/bazelbuild/bazel/commit/6c87715b8ac6b32e636ba307440e2b7362b10a48. When I first tried to roll forward this CL I missed one place where PyCcLinkParamsProvider.TO_LINK_PARAMS should have been called. The target //production/midas/config:client_config_pb builds fine now. RELNOTES:none PiperOrigin-RevId: 201070354
* Expose single_jar and bootclasspath in the java toolchain to skylark.Gravatar Googler2018-06-18
| | | | | | This would allow pulling these from the toolchain in kotlin rules. PiperOrigin-RevId: 200996334
* Make java_toolchain attribute Environment aware.Gravatar dbabkin2018-06-18
| | | | | RELNOTES:none: PiperOrigin-RevId: 200988244
* RepositoryFunction: depend on overrides, even if there is no ruleGravatar Klaus Aehlig2018-06-18
| | | | | | | | | | Not all bazel external repositories are generated by a rule (e.g., they might be unbound names with the expectation that on override binds them). Still, even those external repositories depend on changes to the repository override. Register this dependency. Change-Id: I900c94f969d08dec82c5776eff28337878379b5e PiperOrigin-RevId: 200974283
* Allow CppCompilationHelper to disable coverage instrumentationGravatar Googler2018-06-15
| | | | | RELNOTES=None PiperOrigin-RevId: 200800112
* Remove LIPO supportGravatar hlopko2018-06-15
| | | | | RELNOTES: Support for LIPO has been fully removed. PiperOrigin-RevId: 200724578
* Don't propagate empty asset containersGravatar asteinb2018-06-15
| | | | | | | If asset containers are empty, simply discard them rather than propagating them up the dependency graph. We don't currently use merging output except at the top level, so we don't need any of this information. (If/when asset merging is redone, we'd need to redo this code anyway.) RELNOTES: none PiperOrigin-RevId: 200721055
* Remove CcCompilationContext.TransitiveModuleHeaders#getTransitiveModules. ↵Gravatar cpeyser2018-06-15
| | | | | | This information is persisted for testing only, and considerably slows NestedSet serialization. PiperOrigin-RevId: 200710549
* Enable automatic trimming of test configuration when entering non-test rules.Gravatar mstaib2018-06-14
| | | | | | | | | | | | | | Note that this is not sufficient to see caching between builds on its own; currently when any flag changes, the analysis cache is reset. A follow-up will turn off this behavior when only test flags change while trim_test_configuration is on. config_settings which examine test options are treated the same as test rules; that is, they can only be successfully analyzed at the top level or when connected to the top level by an unbroken chain of test rules. RELNOTES: None. PiperOrigin-RevId: 200614584
* SerializationCheckingGraph checks all ConfiguredTargetValues.Gravatar cpeyser2018-06-14
| | | | PiperOrigin-RevId: 200593618
* Expose new methods in CcToolchainProvider to eventually replace skylark ↵Gravatar juliexxia2018-06-14
| | | | | | callables that depend on CToolchain in CppConfiguration. PiperOrigin-RevId: 200559893
* Support unconditional fetching of repositoriesGravatar Klaus Aehlig2018-06-14
| | | | | | | | | | | Make all external repositories depend on an additional SkyValue controllable via commands, so support unconditional fetching of all external repositories, as it is needed by the the `sync` command. Improves on #5175, provides a work around for #4907. Change-Id: I30033614c1a2fad3f1363b85ff69cf92f697c255 PiperOrigin-RevId: 200543985
* C++: Fixes error reporting for cc_importGravatar plf2018-06-14
| | | | | RELNOTES:none PiperOrigin-RevId: 200525022
* Serialize lambdas when they are cast to Serializable.Gravatar janakr2018-06-13
| | | | | | We could conceivably do some monkey-patching at server startup to make all lambdas act Serializable, but one step at a time. PiperOrigin-RevId: 200509321
* @AutoCodec stray usage of AndroidDataConverter. It should always be a static ↵Gravatar janakr2018-06-13
| | | | | | | | | | constant. This allows us to continue using lambdas in its definition. This is a partial rollback of https://github.com/bazelbuild/bazel/commit/ed1e7594b23100f89755491f36e46886b4a51c8d, since the work done to class-ify things there is unnecessary once every instance is @AutoCodec-ed. PiperOrigin-RevId: 200504678
* Populate JavaInfo's annotation_processing field in java_common.compileGravatar kmb2018-06-13
| | | | | | RELNOTES: None. PiperOrigin-RevId: 200471197
* Reconvert the lambdas in AndroidDataConverter to anonymous inner classes.Gravatar mjhalupka2018-06-13
| | | | | | | Tag some static members with @AutoCodec. Replace some lambdas with explicit functions or classes. PiperOrigin-RevId: 200467500
* * Update apple_common.link_multi_arch_binary to return all of its providers ↵Gravatar allevato2018-06-13
| | | | | | | | and output groups. * Make ctx a keyword argument so that we can more easily add more parameters in the future and eventually remove ctx. PiperOrigin-RevId: 200453550
* Enable per-target execution for genrule, sh_*, and *_test.Gravatar jcater2018-06-13
| | | | PiperOrigin-RevId: 200410988
* Avoid long, duplicated directory structures. In the common case, generatedGravatar Googler2018-06-13
| | | | | | | | files are going to be beneath the target that generates them. In this case, don't duplicated the package's path. RELNOTES: None. PiperOrigin-RevId: 200400464
* Remove supports_lipo field from DefaultCpuToolchainGravatar rosica2018-06-13
| | | | | RELNOTES: None. PiperOrigin-RevId: 200399094
* Add "toolchain-identifier" attribute to cc_toolchain ruleGravatar rosica2018-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the selection of C++ toolchain configuration depends on 2 different things: 1. CROSSTOOL file: a proto text file that contains multiple CrosstoolConfig.CToolchain messages, out of which we want to select the appropriate CToolchain; 2. cc_toolchain_suite rule, specified by --crosstool_top option: this rule contains "toolchains" map attribute. The map's keys are of type <cpu>|<compiler>, or just <cpu>, and the values are labels of cc_toolchain rules (which contain additional C++ information). If there is an entry in cc_toolchain_suite.toolchains that corresponds to the --cpu and --compiler options, we use it, otherwise we loop through all the CToolchains in the CROSSTOOL file, select the one that corresponds to the --cpu and --compiler options, and then get the cc_toolchain label from cc_toolchain_suite.toolchains[toolchain.targetCpu|toolchain.compiler]. In both cases we read the CROSSTOOL file and pass all its information forward, to be used in creation of CppConfiguration and CcToolchainProvider creation. As part of the efforts of rewriting CROSSTOOL in Skylark, we need to make obtaining the cc_toolchain label independent of the CROSSTOOL file and toolchain selection. As a step towards that goal, we add a new "toolchain_identifier" attribute to cc_toolchain, which uniquely identifies a CToolchain in the CROSSTOOL file. Now the process of getting the CToolchain goes as follows: Check for existence of cc_toolchain_suite.toolchains[<cpu>|<compiler>], if --compiler is specified, otherwise check for cc_toolchain_suite.toolchains[<cpu>]. 1. if a value is found, load the cc_toolchain rule and look for the toolchain_identifier attribute. 1.a if the attribute exists, loop through all the CToolchains in CROSSTOOL and select the one with the matching toolchain identifier. 1.b otherwise fall back to selecting the CToolchain from CROSSTOOL by matching the --cpu and --compiler values. 2. If a value is not found, select the CToolchain from CROSSTOOL by matching the --cpu and --compiler values, and construct the key as follows: <toolchain.cpu>|<toolchain.compiler>. In the future we will get rid of 2. by making sure that cc_toolchain_suite.toolchains[<cpu>|<compiler>] and cc_toolchain_suite.toolchains[<cpu>] are always defined. 1.b will be removed by making the cc_toolchain.toolchain_identifier attribute mandatory After this deriving the cc_toolchain label will be independent of the CROSSTOOL file 1.a will ultimately be replaced by an attribute that points to a skylark_crosstool rule, that will contain all the information that CROSSTOOL contains, allowing us to remove CROSSTOOL altogether. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 200388550
* Return Strings from C++ Skylark APIs, not PathFragmentsGravatar hlopko2018-06-13
| | | | | | | | | | PathFragments are not well supported in Skylark, quite the opposite, the Skylark team tries hard to not use path fragments if possible. All existing users I looked into had to convert the PathFragment to string using str() anyway. Because of that this cl should not break anybody. RELNOTES: None. PiperOrigin-RevId: 200372447
* C++: Continues renaming executionDynamicLibraries to dynamicLibrariesForRuntime.Gravatar plf2018-06-13
| | | | | RELNOTES:none PiperOrigin-RevId: 200366616
* Change generated DEF file name from <target name>.def to <target name>.gen.defGravatar pcloudy2018-06-13
| | | | | | | | | This helps avoid name conflicts when users want to generate DEF files by themselves. For example, when using a genrule to do that, people naturally name the def file as <target name>.def. Fixed https://github.com/bazelbuild/bazel/issues/5357 RELNOTES: None PiperOrigin-RevId: 200354303
* Change the default value of ↵Gravatar dannark2018-06-12
| | | | | | | | --experimental_android_local_test_binary_resources to true. RELNOTES[NEW]: android_local_test now takes advantage of Robolectric's binary resource processing which allows for faster tests. PiperOrigin-RevId: 200296572
* Automated rollback of commit a1c9f8d33457cd1f3b01299863bcab2667c13a52.Gravatar Googler2018-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** PY3 does not support Python proto1. *** Original change description *** Automated rollback of commit 4c72a82ada742bd369185cd07c57f96c497ce440. *** Reason for rollback *** Breaks, at least, //ads/aswan/tools:format_mr_results. *** Original change description *** Remove python3/ prefix to generated .pyc files. That makes: (a) merging PY2 and PY3 .runfiles impossible (which is incorrect anyway) and (b) generated .py source files incompatible with 2to3 (src_version=PY2) - that's OK as we deprecate 2to3. RELNOTES: n/a PiperOrigin-RevId: 200256210
* Add skylarkbuildapi bootstraps for apple, cpp, platform, and testing packagesGravatar cparsons2018-06-12
| | | | | RELNOTES: None. PiperOrigin-RevId: 200246780
* Split TargetPatternEvaluator into two interfacesGravatar ulfjack2018-06-12
| | | | | | | | | | | | | | | | | - the TargetPatternPreloader is still used for query in all its forms - the remaining TargetPatternEvaluator part is no longer used except in tests - also make both implementations stateless and pass the offset to the methods instead; note that they both modify the underlying skyframe graph, so there are side effects to the calls even if there's no direct state anymore The intent is to migrate the relevant tests to LoadingPhaseRunnerTest (which could also now be renamed since it's not doing a loading phase), and then delete the TargetPatternEvaluator interface. This depends on the previous commit that removed the last direct use of TPE from an internal command. PiperOrigin-RevId: 200198067
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 10:29:36 +0000