aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/packages/RuleClassProvider.java
Commit message (Collapse)AuthorAge
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* Skylark: the native module is refactored and documented.Gravatar Googler2015-03-24
| | | | | | | | - SkylarkNativeModule is added to handle to native module. - Glob function is migrated to be a SkylarkFunction. Note that other functions in the native module are more difficult to migrate since they are not static. -- MOS_MIGRATED_REVID=89292579
* Parse built-in WORKSPACE filesGravatar Kristina Chodorow2015-02-11
| | | | | | | | This doesn't actually add any default workspace files, yet, but adds machinery for them. Also did some cleanup/renaming. -- MOS_MIGRATED_REVID=86085127
* Update from Google.Gravatar Han-Wen Nienhuys2015-02-25
-- MOE_MIGRATED_REVID=85702957