aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/ConfiguredRuleClassProvider.java
Commit message (Collapse)AuthorAge
* 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
* Move Label from the lib.syntax to the lib.cmdline package so that:Gravatar Lukacs Berki2015-09-21
| | | | | | | | | | - Label parsing can be simplified - lib.syntax is only contains the code for Skylark and is reasonably independent from the problem domain of building things This change is mostly only changes to imports declarations. The rest is reversing the dependency between :cmdline and :syntax and moving a tiny amount of code between Printer and FilesetEntry and the addition of SkylarkPrintableValue that I couldn't be bothered to separate out into its own change. -- MOS_MIGRATED_REVID=103527877
* Parse the label syntax "@//a:b" so that eventually we can make that the ↵Gravatar Lukacs Berki2015-09-15
| | | | | | | | | syntax that means "refer to the main repository". There isn't an overarching plan for what we are going to do with the cmdline package, which seems to be separated from the .syntax one in all sorts of awkward ways. -- MOS_MIGRATED_REVID=103088960
* Refactor Skylark Environment-sGravatar Francois-Rene Rideau2015-09-11
| | | | | | | | | | | | | | | | | | | | Make Environment-s freezable: Introduce a class Mutability as a revokable capability to mutate objects in an Environment. For now, only Environment-s carry this capability. Make sure that every Mutability is revoked in the same function that create... This reinstates a change that previously rolled-back because it broke the serializability of SkylarkLookupValue. Bad news: serializing it succeeds for the wrong reason, because a SkylarkEnvironment was stored as a result (now an Environment.Extension) that was Serializable but inherited its bindings from an Environment (now an Environment.BaseExtension) which wasn't Serializable. Apparently, Java doesn't try to serialize the bindings then (or at least doesn't error out when it fails), because these bindings map variable names to pretty arbitrary objects, and a lot of those we find in practice aren't Serializable. Thus the current code passes the same tests as the previous code, but obviously the serialization is just as ineffective as it used to be. -- MOS_MIGRATED_REVID=102776694
* Rollback of commit 5a94e59f02833f9142bad9203acd72626b089535.Gravatar Janak Ramakrishnan2015-09-08
| | | | | | | | | *** Reason for rollback *** Breaks serialization of SkyValues. -- MOS_MIGRATED_REVID=102457225
* Refactor Skylark Environment-sGravatar Francois-Rene Rideau2015-09-08
| | | | | | | | | | | | | | | | | Make Environment-s freezable: Introduce a class Mutability as a revokable capability to mutate objects in an Environment. For now, only Environment-s carry this capability. Make sure that every Mutability is revoked in the same function that creates it, so no Environment is left open for modification after being created and exported; exceptions for tests, the shell and initialization contexts. Unify Environment, SkylarkEnvironment and EvaluationContext into Environment. Have a notion of Frame for the bindings + parent + mutability. Replace the updateAndPropagate mechanism by a dynamicFrame. Simplify ValidationEnvironment, that is now always deduced from the Environment. -- MOS_MIGRATED_REVID=102363438
* Inject the default runfiles prefix from the rule class provider.Gravatar Ulf Adams2015-09-04
| | | | | -- MOS_MIGRATED_REVID=102341264
* Inject the prelude path through the rule class provider.Gravatar Ulf Adams2015-09-01
| | | | | -- MOS_MIGRATED_REVID=102020499
* Add a isLoadingPhase flag to EnvironmentGravatar Francois-Rene Rideau2015-08-27
| | | | | | | | | Have loadingPhase-only methods check that flag. It's no use removing the initial bindings to these methods when they may have been copied anyway. -- MOS_MIGRATED_REVID=101624770
* Create ValidationEnvironment from EnvironmentGravatar Francois-Rene Rideau2015-08-27
| | | | | | | | Allow ValidationEnvironment to be created from initial Environment so that there is no need to manually keep two different sets of constructors in synch. -- MOS_MIGRATED_REVID=101588695
* A prototype implementation of top-level aspects.Gravatar Dmitry Lomov2015-08-20
| | | | | -- MOS_MIGRATED_REVID=101033236
* Get jdk.WORKSPACE into the default WORKSPACE file by reading it as a Java ↵Gravatar Lukacs Berki2015-06-15
| | | | | | | | | | | resource, then passing it to the parser as a string instead of putting it into embedded_binaries then passing a Path to it to the parser. This makes the upcoming default WORKSPACE rules for Android much more palatable. In particular, Android rules won't need to be special cased when building the Bazel binary because the contents are self-contained in BazelRuleClassProvider (and the jdk.WORKSPACE file, which is a simple Java resource) Even better would be not to use a string, but some kind of structured data, but that's probably more effort than it's worth. -- MOS_MIGRATED_REVID=95983199
* Simplify ValidationEnvironment.Gravatar Laurent Le Brun2015-04-16
| | | | | | | We need only a set of symbols, types are not used anymore. -- MOS_MIGRATED_REVID=91299566
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 00:27:39 +0000