| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
descriptor objects.
Build settings are units of configuration i.e. a key/value pair of a setting (e.g. cpu) and a value (e.g. ppc). A build setting descriptor is used to describe what kind of build setting a skylark rule is (if any at all). The BuildSettingDescriptor implementation of the API describes two facets of the build setting rule: the type of the value and whether or not the setting is settable on the command line.
The methods exposed here will eventually be hooked up to a new parameter in the <code> rule() </code> function. Validation for these restrictions will also happen in a later CL attached to the same bug.
PiperOrigin-RevId: 208669663
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove MergableAndroidData interface, and clean up various converters to
explicitly use ParsedAndroid{Resources|Assets}
- Remove calls to getters that always return an empty list (based on the above
cleanup)
- Stop passing around empty transitiveAssets in ResourceDependencies and
AndroidResourcesInfo
- Remove no-op getter method for decoupling settings in AndroidConfiguration
Also, consolidate all AndroidDataConverter instances that were used in multiple
places into the AndroidDataConverter class, rather than declaring them in
multiple places. Add a bit of documentation as to which objects they represent
in the action code, which should make mapping between one and the other easier.
RELNOTES: none
PiperOrigin-RevId: 208042452
|
| |
|
|
|
|
|
| |
Previously, only trivial relative paths (within the same package) were handled correctly. Now paths such as ":foo/bar.bzl" are handled appropriately.
RELNOTES: None.
PiperOrigin-RevId: 206237161
|
| |
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 206195789
|
| |
|
|
|
| |
RELNOTES: none.
PiperOrigin-RevId: 206035420
|
| |
|
|
|
|
|
| |
Working towards #4570.
RELNOTES:none
PiperOrigin-RevId: 205274676
|
| |
|
|
|
|
|
|
|
| |
files which define new provider types and instantiate Labels.
Also improve docstring usage in attr definitions by doing whitespace trimming.
RELNOTES: None.
PiperOrigin-RevId: 204537623
|
| |
|
|
|
|
|
| |
Previously, any absolute label (starting with double slash) would be converted to an absolute path, instead of a path relative to the current workspace directory.
RELNOTES: None.
PiperOrigin-RevId: 204472080
|
| |
|
|
|
|
|
|
| |
- Change Skydoc to only document exported symbols in the target file, instead of all exported symbols in the transitive dependencies of the target file. This circumvents a prior error scenario where main.bzl could depend on dep.bzl, and both export a rule named ?my_rule?, which would result in a conflict.
- Offer the option to specify whitelisted symbols for which to output documentation, allowing a user to only request documentation for a subset of rules defined in a given file. This allows more granular control of documentation layout.
RELNOTES: None.
PiperOrigin-RevId: 204161197
|
| |
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 204147228
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Previously we would zip the output of dsymutil and then proceed to unzip it.
Due to the size of dSYM files, this could add a few seconds to all builds
with dSYMs.
- There's no need to have a DsymOutputType or even Info.plist as all we need
is the DWARF symbol file; the dSYM is repackaged later on by the bundler.
This change is synchronized with the CROSSTOOL and wrapped_clang via the
`no_dsym_create_zip` feature, which Bazel sets on the CROSSTOOL to inform
wrapped_clang that no zip file should be created for the dSYM.
PiperOrigin-RevId: 204134986
|
| |
|
|
|
|
|
| |
This uses apache velocity engine templates to create markdown-HTML. There are other alternatives, but there is already precedent for depending on this library from docgen.
RELNOTES: None.
PiperOrigin-RevId: 203795431
|
| |
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 202943806
|
| |
|
|
|
|
|
| |
objects for Skydoc.
RELNOTES: None.
PiperOrigin-RevId: 202697176
|
| |
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 202690562
|
| |
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 202685157
|
| |
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 202677272
|
| |
|
|
|
|
|
| |
test packages.
RELNOTES: None.
PiperOrigin-RevId: 202642995
|
| |
|
|
|
|
|
| |
Skydoc will generate documentation for all rule definitions in the transitive dependencies of the given input file.
RELNOTES: None.
PiperOrigin-RevId: 202553088
|
| |
|
|
|
|
|
| |
These fakes won't behave at all like real implementations at this time. In fact, invoking some of their methods (or accessing their fields) may result in an error. This serves, however, as the initial check-in which can be iterated on and improved later.
RELNOTES: None.
PiperOrigin-RevId: 202525168
|
| |
|
|
|
|
|
|
|
| |
This is a much cleaner, more elegant approach than previous regex matching.
This still leaves room for unknown-name rule definitions, in case, for example, a user namespaces their rule definition not at the top level.
For example: "foo.bar = rule(...)"
RELNOTES: None.
PiperOrigin-RevId: 202380975
|
|
|
This skydoc rewrite uses an actual skylark interpreter with a faked build API (implementing the actual build API that Bazel uses).
There's a lot left to do here, this is a barebones start.
For example, this does not yet handle:
- load() statements
- non-global build API elements (e.g. apple_common)
- output of any rule information other than attribute names
- markdown output format
RELNOTES: None.
PiperOrigin-RevId: 202187207
|
juliexxia
asteinb
cparsons
Googler
plf