| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
RELNOTES[NEW]: TemplateVariableInfo can now be constructed from Skylark.
PiperOrigin-RevId: 194072452
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
JavaRuntimeInfo.
Change-Id: Ic338dc9b3e5efa2fee92dba722a46cab743db40c
PiperOrigin-RevId: 182919931
|
|
|
|
|
|
|
| |
access.
Change-Id: I6041c51823fa52d6ae55dfe06afd1754ce05ab98
PiperOrigin-RevId: 182904580
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Make variables provider.
RELNOTES: None.
PiperOrigin-RevId: 173527191
|
|
|
|
|
|
| |
Progress on #2475.
PiperOrigin-RevId: 170473111
|
|
|
|
|
|
| |
Progress on #2475.
PiperOrigin-RevId: 170197341
|
|
|
|
|
|
| |
This is a trivial change with a large file footprint.
PiperOrigin-RevId: 169169864
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165910455
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164456961
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164446955
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161527470
|
|
|
|
|
|
|
| |
dependency.
RELNOTES: None.
PiperOrigin-RevId: 161504700
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161383469
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
This is required for compatibility with existing runtimes specified
as filegroups.
--
PiperOrigin-RevId: 145314598
MOS_MIGRATED_REVID=145314598
|
|
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
|