aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/java/JavaRuntime.java
Commit message (Collapse)AuthorAge
* Make the constructor of TemplateVariableInfo available in Skylark.Gravatar lberki2018-04-24
| | | | | | RELNOTES[NEW]: TemplateVariableInfo can now be constructed from Skylark. PiperOrigin-RevId: 194072452
* Expose an actions provider on RuleConfiguredTarget instances.Gravatar cparsons2018-03-06
| | | | | | | | | Given a target (for example from a skylark aspect), one will be able to access a list of actions that the target generated using "target.actions". This is without additional memory footprint. Actions themselves are not fully exposed to skylark (and thus there isn't much meaning to gather from them in skylark yet). Access methods will follow soon. RELNOTES: None. PiperOrigin-RevId: 188098079
* Move all code to lookup JavaRuntimeInfo to static methods onGravatar John Cater2018-01-23
| | | | | | | JavaRuntimeInfo. Change-Id: Ic338dc9b3e5efa2fee92dba722a46cab743db40c PiperOrigin-RevId: 182919931
* Add JavaRuntimeToolchainInfo class to wrap JavaRuntimeInfo for toolchains ↵Gravatar John Cater2018-01-23
| | | | | | | access. Change-Id: I6041c51823fa52d6ae55dfe06afd1754ce05ab98 PiperOrigin-RevId: 182904580
* Move the javabase middleman to within JavaRuntimeInfo.Gravatar lberki2017-12-07
| | | | | | | | | | | This is necessary bacause //tools/jdk:current_host_java_runtime is implemented in Skylark, and we don't (and shouldn't) have a way to create MiddlemanProvider from there. However, we are planning to move to the the java_runtime_alias/java_host_runtime_alias rules as the exclusive representation of the javabase, so we need to be able to make one from Skylark. Previously, this wasn't a problem, because if the javabase was a filegroup (like //tools/defaults:jdk), the path to the Java binary was taken from the configuration and the middleman from the filegroup, but since we are removing that information from the configuration, we can't do that anymore. RELNOTES: None. PiperOrigin-RevId: 178242307
* Add platform_common.MakeVariableInfo so that Skylark code has access to the ↵Gravatar lberki2017-10-27
| | | | | | | Make variables provider. RELNOTES: None. PiperOrigin-RevId: 173527191
* Move expansion functionality to a new classGravatar ulfjack2017-09-29
| | | | | | Progress on #2475. PiperOrigin-RevId: 170473111
* Simplify make variable expansion call sitesGravatar ulfjack2017-09-28
| | | | | | Progress on #2475. PiperOrigin-RevId: 170197341
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Rename some of native declared providers according to the new naming scheme.Gravatar dslomov2017-08-21
| | | | | RELNOTES: None PiperOrigin-RevId: 165910455
* Move MakeVariableProvider to lib.analysisGravatar ulfjack2017-08-08
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164456961
* 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
* MakeVariableProvider should be declared provider only.Gravatar dslomov2017-07-11
| | | | | RELNOTES: None. PiperOrigin-RevId: 161527470
* Make information about the Java runtime in use available in Skylark using a ↵Gravatar lberki2017-07-11
| | | | | | | dependency. RELNOTES: None. PiperOrigin-RevId: 161504700
* Add Make variables to java_runtime and java_runtime_suite .Gravatar lberki2017-07-11
| | | | | | | This is necessary so that Make variables are not accessed from BuildConfiguration, which is in turn necessary so that we can forego package loading during configuration creation (currently we need to parse the java_runtime_suite / java_runtime rules to create the Jvm fragment) RELNOTES: None. PiperOrigin-RevId: 161496779
* Make jvm_runtime.java_home expand Make variables.Gravatar lberki2017-07-10
| | | | | RELNOTES: None. PiperOrigin-RevId: 161383469
* Plumb some information about the location of the JVM through ↵Gravatar lberki2017-07-07
| | | | | | | | | | | | | | | JavaRuntimeProvider instead of Jvm if a java_runtime rule is used. There are a few things standing in the way of removing package loading from JvmConfigurationLoader: - The JAVABASE/JAVA Make variables, which are a function of the contents of the package with the JVM. The plan is to make JavaRuntime a MakeVariableProvider and add an attribute to rules that do Make variable evaluation to tell which Make variables they need - The path to the Java binary is exported to Skylark through the configuration fragment. We'll need to export an attribute to Skylark that can be used to depend on the JVM, then do the three-step dance to use that instead of the configuration and figure out what to do if --javabase is not a label. - Jvm#getJavaExecutable() has a bunch of call sites. They need to be adjusted individually. RELNOTES: None. PiperOrigin-RevId: 161176462
* Add java_runtime contents to runfilesGravatar Liam Miller-Cushon2017-01-24
| | | | | | | | | This is required for compatibility with existing runtimes specified as filegroups. -- PiperOrigin-RevId: 145314598 MOS_MIGRATED_REVID=145314598
* Initial implementation of java_runtime and java_runtime_suiteGravatar Liam Miller-Cushon2017-01-17
These rules can be used to configure JDKs, as an alternative to the filegroups and filegroups-of-filegroups used currently. -- PiperOrigin-RevId: 144655277 MOS_MIGRATED_REVID=144655277