aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/ConfiguredRuleClassProvider.java
Commit message (Collapse)AuthorAge
* Introduce cc_toolchain_type, which exports c++ make variables. UseGravatar cpeyser2017-11-07
| | | | | | //tools/cpp:toolchain_type as the canonical c++ toolchain. PiperOrigin-RevId: 174759558
* Expose late-bound-attributes to Skylark.Gravatar cparsons2017-11-06
| | | | | RELNOTES: Late-bound attributes are exposed to skylark. This is a new API (`configuration_field()`) to depend on certain configuration-defined targets from skylark rules. PiperOrigin-RevId: 174534104
* PiperOrigin-RevId: 173660429Gravatar lpino2017-10-27
|
* Pass SkylarkSemantics through Skyframe instead of the options classGravatar brandjon2017-10-06
| | | | | | | Also remove the use of the @UsesOnlyCoreTypes annotation on SkylarkSemanticsOptions. It was only there to help mark that the options class was safe to put in Skyframe. RELNOTES: None PiperOrigin-RevId: 171248504
* Remove the product name from ConfiguredRuleClassProvider.Gravatar jmmv2017-09-07
| | | | | | | | | | | | | The RuleClassProvider includes a copy of the product name, parameterized for both Blaze and Bazel. Apparently, this is exclusively there so that the standalone docgen binary can "magically" guess the product name. This is strange and adds additional complexity to the Bazel core codebase for no strong reason. Instead, just add a new flag to docgen that takes the product name and pass it in explicitly. RELNOTES: None. PiperOrigin-RevId: 167724033
* Remove ConfigurationCollectionFactory as part of the static config cleanup.Gravatar gregce2017-08-18
| | | | PiperOrigin-RevId: 165578449
* Move the Skylark rule infrastructure from lib.rules to lib.analysis.skylarkGravatar ulfjack2017-08-09
| | | | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. Unfortunately, there are a number of reverse deps from analysis code to Skylark classes, so moving these is the only way to make progress. PiperOrigin-RevId: 164612957
* Move RuleConfiguredTargetFactory to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164446955
* Apply native binary launcher to sh_binaryGravatar Yun Peng2017-07-31
| | | | | | | | | | | | This change: 1. Added launcher to @bazel_tools If the host platform is Windows, we use a prebuilt launcher.exe , otherwise the launcher needs to be built with MSVC first. 2. Launching sh_binary using native launcher. Change-Id: I5a63135455057fbfe04ff0cce7ec7994ef0c347a PiperOrigin-RevId: 163442540
* Remove --experimental_dynamic_configs=notrim_partial.Gravatar gregce2017-07-26
| | | | | | Part of the static configuration removal cleanup. PiperOrigin-RevId: 163130922
* Factor out BuildConfigurationCollection.Transitions.getDynamicTransition.Gravatar gregce2017-07-07
| | | | | | | | | | | | This is a legacy dependency on the configuration transition table, which is only needed for static configurations. Dynamic configurations didn't actually use anything in that table: this was just a convenience interface that could have equally been defined somewhere else. So this cl defines it somewhere else. There's still one last dependency: Transitions.configurationHook. We'll tackle that in a followup cl. PiperOrigin-RevId: 161141650
* Use the same data structure for native and Skylark providers.Gravatar dslomov2017-07-05
| | | | | | | | | The memory cost of adding Skylark provider is now the same as native. Skylark providers (declared and legacy) benefit from the same shape-sharing optimization as native providers. RELNOTES: None. PiperOrigin-RevId: 160944263
* Clean up Environment.FrameGravatar brandjon2017-05-09
| | | | | | | | | Make fields visibility/accessors more idiomatic. Prefer accessors that give a full map of the bindings and inherited bindings, rather than just the keys. Also increase visibility of some accessors on Mutability. RELNOTES: None PiperOrigin-RevId: 155393780
* Make Skylark interpreter read Skylark command-line flagsGravatar brandjon2017-04-30
| | | | | | | | | | | This is the second of two CLs for making command line options able to affect the Skylark interpreter. For the main kinds of evaluation contexts -- package loading, .bzl loading, rule analysis, aspect analysis, and computed defaults -- the SkylarkSemanticsOptions object is retrieved from Skyframe and passed along to the Environment builder. For other contexts such as tests, default values of builtin functions, and standalone Skylark, flags are currently not processed. In the future, we may want to split into separate files the options that affect "pure" Skylark vs the options that affect Bazel-flavored Skylark. One possibility is to subclass SkylarkSemanticsOptions into SkylarkBazelSemanticsOptions, and go through an indirection in SkylarkUtils. We could also pass SkylarkSemanticsOptions to the parser, to support --incompatible_* changes that alter Skylark's syntax. I don't think that's needed at the moment. RELNOTES: None PiperOrigin-RevId: 154628391
* Make a rogue test case honor --experimental_dynamic_configs=notrim_partial ↵Gravatar Greg Estren2016-12-05
| | | | | | | | | | like everywhere else. Unfortunately this doesn't use ConfiguredRuleClassProvider to prepare its configuration's BuildOptions like every other code path does. -- PiperOrigin-RevId: 140873428 MOS_MIGRATED_REVID=140873428
* Add option to disable dynamic configs with LIPO.Gravatar Greg Estren2016-12-02
| | | | | | | | | | | | New option --experimental_dynamic_configs=notrim_partial automatically switches to --experimental_dynamic_configs=off if any BuildOptions fragment sets useStaticConfigurationsOverride(). CppOptions implements this override for FDO/LIPO. -- PiperOrigin-RevId: 140864317 MOS_MIGRATED_REVID=140864317
* Remove isSkylark and eval from Environment.Gravatar Laurent Le Brun2016-11-29
| | | | | -- MOS_MIGRATED_REVID=140371603
* Fix a bunch of typosGravatar Jon Brandvein2016-11-10
| | | | | -- MOS_MIGRATED_REVID=138757881
* Small docs updates for the extra action rule.Gravatar Ulf Adams2016-10-28
| | | | | | | | Add the product name to the ConfiguredRuleClassProvider so that the doc generator can generate the proper links to the user manual. -- MOS_MIGRATED_REVID=137505460
* Move ToolsRepository out of EnvironmentGravatar Laurent Le Brun2016-10-27
| | | | | | | | | Other fields will follow (is_skylark, phase, callerLabel). The goal is to make Environment (and more generally Skylark) less dependent on Bazel. -- MOS_MIGRATED_REVID=137386248
* Move the RuleModule interface to ConfiguredRCP and rename it to RuleSet.Gravatar Ulf Adams2016-10-19
| | | | | -- MOS_MIGRATED_REVID=136463385
* Refactor the rule class provider.Gravatar Ulf Adams2016-10-18
| | | | | | | | | | | | - add a convenience method to make adding options + fragment factories a bit simpler - sort the objc rules alphabetically - split the j2objc rules from the objc rules - unfortunately, the objc rules depend on the j2objc configuration, so that has to stay -- MOS_MIGRATED_REVID=136442577
* Rename field to clarify function.Gravatar Ulf Adams2016-10-14
| | | | | -- MOS_MIGRATED_REVID=136152771
* Don't inherit the host configuration's fragments from the target config in ↵Gravatar Greg Estren2016-10-05
| | | | | | | --experimental_dynamic_configs=notrim mode. -- MOS_MIGRATED_REVID=135126724
* Enable aspect invocations to be matched by output filters.Gravatar Michael Staib2016-09-19
| | | | | | | | | | | | | Currently aspects have no tag, i.e., they don't get checked against output filters at all. This changes aspects to have a tag of the same form as the rule they are attached to (i.e., the label of the target). Since the default output filters match on ^//package[:/], this should cover most uses of the output filter, while still allowing for finer control for those who crave it. -- MOS_MIGRATED_REVID=133425215
* Add deprecation support to Bazel.Gravatar Michael Staib2016-09-19
| | | | | | | | | | | | | | | | | | Bazel has always had a deprecation attribute, but until now it has been a no-op. After this change, Bazel will warn when a target with the deprecated attribute unset depends on one with the deprecated attribute set. Like all other warnings, this warning will only be displayed when it matches the output filter. It is also bypassed if the two targets are in the same package. RELNOTES: The deprecation attribute of all rules now causes warnings to be printed when other targets depend on a target with that attribute set. -- MOS_MIGRATED_REVID=133415232
* Add a ServerBuilder, and use that in the module API.Gravatar Ulf Adams2016-07-07
| | | | | | | This change is similar to a previous change that introduced WorkspaceBuilder. -- MOS_MIGRATED_REVID=126799657
* Split up BazelRuleClassProvider, and make the builder API more flexible.Gravatar Ulf Adams2016-07-06
| | | | | | | | | This is in preparation for splitting up the rules into per-language modules. We'll also add test coverage to make sure each module is individually useful, so that it's possible to build a Bazel binary with a reduced set of rules. -- MOS_MIGRATED_REVID=126672702
* --Gravatar Luis Fernando Pino Duque2016-07-04
| | | | MOS_MIGRATED_REVID=126410490
* Simplify RuleClassProvider; it kept two identical lists for no purpose.Gravatar Ulf Adams2016-06-23
| | | | | | | | Also update HelpCommand to output the configuration options in the hmtl output. -- MOS_MIGRATED_REVID=125570665
* Introduces a registry of native providers to the BuildConfiguration, which ↵Gravatar Cal Peyser2016-05-03
| | | | | | | can be added to by fragments. Uses the registry to enable native access to TranstiveProviderInstances from Skylark. In particular, makes ObjcProvider accessible to skylark rule implementations. -- MOS_MIGRATED_REVID=121390911
* Inject the Constants.TOOLS_REPOSITORY in SkylarkRuleClassFunctions.testBaseRule Gravatar Luis Fernando Pino Duque2016-04-29
| | | | | | | | | | | | | via the Skylark and delete the constant. Also, change the isLoadingPhase in the Skylark environment an enum Phase in order to: - Decide whether testRules are enabled or not and, - Check that the toolsRepository is set when in the LOADING phase. Finally, a few tests that were using ConfiguredRuleClassProvider directly had to be updated to set a tools repository, otherwise createGlobals() fails. -- MOS_MIGRATED_REVID=121022804
* Delete the interface NativeAspectFactory and make native aspects extend from ↵Gravatar Luis Fernando Pino Duque2016-04-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NativeAspectClass. This a large refactoring of the aspects, currently we have the following: - AspectClasses: The interface AspectClass is a implemented by either SkylarkAspectClass or NativeAspectClass<NativeAspectFactory>. They are wrappers for the AspectFactories and they hold the information about the Class<> of the factory. - AspectFactories (FooAspect.java): Represented by the interfaces ConfiguredAspectFactory and NativeAspectFactory, also by the interface ConfiguredNativeAspectFactory which is the union of the two aforementioned interfaces. All aspects implement ConfiguredNativeAspectFactory except Skylark aspects which implement only ConfiguredAspectFactory. After this CL the distinction between NativeAspectFactories and NativeAspectClasses dissappear, namely aspect that extends NativeAspectClass is considered native and if it implements ConfiguredAspectFactory it is configured. Therefore the interfaces NativeAspectFactory and ConfiguredNativeAspectFactory both disappear. With this refactoring the aspectFactoryMap in the ConfiguredRuleClassProvider changes its type from (String -> Class<? extends NativeAspectClass>) to (String -> NativeAspectClass) which means it is now able to have an instance of the aspect instead of its Class only. By doing this, it is now possible to pass parameters when creating an aspect in the ConfiguredRuleClassProvider. -- MOS_MIGRATED_REVID=120819647
* Fix the documentation generator to use rule definition instances instead of ↵Gravatar Luis Fernando Pino Duque2016-04-26
| | | | | | | classes. -- MOS_MIGRATED_REVID=120794657
* Register instances instead of classes as Skylark-visible globals.Gravatar Dmitry Lomov2016-04-22
| | | | | -- MOS_MIGRATED_REVID=120538736
* Make C++ autoconfigured toolchain the default for Linux and OS X.Gravatar Damien Martin-Guillerez2016-03-31
| | | | | | | This is done by adding a default workspace suffix. -- MOS_MIGRATED_REVID=118656979
* Always apply invocation policy when constructing build options.Gravatar Janak Ramakrishnan2016-03-24
| | | | | -- MOS_MIGRATED_REVID=117939121
* Make labels in .bzl files in remote repos resolve relative to their repoGravatar Kristina Chodorow2016-03-21
| | | | | | | | | | | | | | | | | | For example, if you have a BUILD file that does: load('@foo//bar:baz.bzl', 'my_rule') my_rule(...) If baz.bzl uses Label('//whatever'), this change makes //whatever resolve to @foo//whatever. Previous to this change, it would be resolved to the repository the BUILD file using my_rule was in. RELNOTES[INC]: Labels in .bzl files in remote repositories will be resolved relative to their repository (instead of the repository the Skylark rule is used in). -- MOS_MIGRATED_REVID=117720181
* Enable injection of Skylark modules through the RuleClassProviderGravatar Damien Martin-Guillerez2016-02-15
| | | | | | | | | | | This enable BlazeModule to specify extraneous Skylark modules. This will be used by Skylark remote repositories to add them from the BazelRepositoryModule. Issue #893, step 2 of the roadmap of http://goo.gl/OZV3o0 -- MOS_MIGRATED_REVID=114677157
* Replace getToolsRepository() with getToolsLabel(String labelValue) which ↵Gravatar Luis Fernando Pino Duque2016-02-09
| | | | | | | | | prepends the tools repository path to the given string and parses the result as a label. This is a cleaner way to access the tools repository label. -- MOS_MIGRATED_REVID=114105929
* Inject the TOOLS_REPOSITORY constant in the RuleClassProvider instead of ↵Gravatar Luis Fernando Pino Duque2016-01-28
| | | | | | | | | | | using Constants.java It also includes one example on how to use the new mechanism in BazelCppRuleClasses. This is the first phase for the removal of the TOOLS_REPOSITORY constant. -- MOS_MIGRATED_REVID=113244399
* Enable label-based Skylark loading. In particular, such labels may reference ↵Gravatar John Field2015-12-22
| | | | | | | | | | | | | | | | | | | files in external repositories. In addition: - Cleaned up and refactored some tests to reflect the new loading behavior. Deferred to future CLs: - Updating Bazel Skylark documentation to reflect the new load form. - Enabling command-line loading of Aspects via labels. RELNOTES: Skylark load statements may now reference .bzl files via build labels, in addition to paths. In particular, such labels can be used to reference Skylark files in external repositories; e.g., load("@my_external_repo//some_pkg:some_file.bzl", ...). Path-based loads are now deprecated and may be disabled in the future. Caveats: Skylark files currently do not respect package visibility; i.e., all Skylark files are effectively public. Also, loads may not reference the special //external package. -- MOS_MIGRATED_REVID=110786452
* Make BUILD_OPTIONS privateGravatar Kristina Chodorow2015-12-15
| | | | | -- MOS_MIGRATED_REVID=110153136
* Add the concept of a "universal" configuration fragment, which allGravatar Greg Estren2015-11-16
| | | | | | | | | | | | | | | | | configurations contain regardless of whether their rules explicitly require it. This is used to ensure all rules have BazelConfiguration. That fragment supplies the path to the shell, which powers BuildConfiguration.getShExecutable(), which powers any rule that generates a SpawnAction. Since SpawnActions are such a ubiquitous pattern we only want to accelerate going forward, there's no point not to make this automatically available to every rule. -- MOS_MIGRATED_REVID=107786879
* Use Labels, rather than PathFragments, to represent Skylark loads ↵Gravatar John Field2015-11-13
| | | | | | | | | | | | | | | | | | | | | internally. The load location for a Skylark Aspect is specified via a PathFragment, for consistency with current non-Aspect Skylark loads. This should be a semantics-preserving change for users. In a subsequent CL, I'll change the Skylark syntax to allow load statements to use labels as well as paths, with the goal of eventually deprecating the latter. Also: - Removed the hack for handling relative loads in the prelude file. - Refactored some redundant functionality in PackageFunction and SkylarkImportLookupFunction for handling loads. - Removed the ability to put the BUILD file for the package containing a Skylark file under a different package root than the Skylark file itself. This functionality isn't currently used and is inconsistent with Blaze's handling of the package path elsewhere. - Added BUILD files to a number of tests that load Skylark files; this is consistent with the requirement that all Skylark files need to be part of some package. - Changed the constants used to set the location of the prelude file from paths to labels. -- MOS_MIGRATED_REVID=107741568
* Implement propagation along dependencies for Skylark aspects.Gravatar Dmitry Lomov2015-11-02
| | | | | -- MOS_MIGRATED_REVID=106694515
* Move the check whether a repository name contains a slash to ↵Gravatar Philipp Wollermann2015-10-23
| | | | | | | PackageIdentifier, where it actually belongs. -- MOS_MIGRATED_REVID=106086272
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | The headers were modified with `find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'` And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan. The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand. -- MOS_MIGRATED_REVID=103938715
* Roll back using labels rather than PathFragments for skylark loads.Gravatar Michajlo Matijkiw2015-09-22
| | | | | | | RELNOTES: -- MOS_MIGRATED_REVID=103606693
* Use Labels, rather than PathFragments, to represent Skylark loads ↵Gravatar John Field2015-09-22
| | | | | | | | | | | | | | | | | | | internally. This should be a semantics-preserving change for users. In a subsequent CL, I'll change the Skylark syntax to allow load statements to use labels as well as paths, with the goal of eventually deprecating the latter. Also: - Removed the hack for handling relative loads in the prelude file. - Refactored some redundant functionality in PackageFunction and SkylarkImportLookupFunction for handling loads. - Removed the ability to put the BUILD file for the package containing a Skylark file under a different package root than the Skylark file itself. This functionality isn't currently used and is inconsistent with Blaze's handling of the package path elsewhere. - Added BUILD files to a number of tests that load Skylark files; this is consistent with the requirement that all Skylark files need to be part of some package. - Changed the constants used to set the location of the prelude file from paths to labels. -- MOS_MIGRATED_REVID=103567562