| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102239051
|
|
|
|
|
|
|
| |
given
--
MOS_MIGRATED_REVID=102046602
|
|
|
|
|
|
|
|
|
|
| |
The baseline artifacts are part of the instrumented files provider now, and
are strongly tied to the collect_code_coverage flag. It seems to be simpler
to collect them explicitly in the BuildView (which already collects them for
post-processing), than to rely on the output group selection.
--
MOS_MIGRATED_REVID=101926341
|
|
|
|
|
|
|
|
|
| |
color when the build fails.
Includes fix for problems causing the original slowdown to blaze query
--
MOS_MIGRATED_REVID=99755414
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Query performance regression.
--
MOS_MIGRATED_REVID=99560234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new way to stop applications when deploying incremental
changes that saves the current app state for the next run. This allows things
like the back stack, and View/Fragment/Activity saved state to be restored when
the app next launches, making it easier to quickly iterate on code changes.
It adds a "--start" flag to mobile-install that replaces "--start_app".
--start accepts an argument describing the mode: no, cold, or warm. "no" is
now the equivalent of "--nostart_app", "cold" is the equivalent of
"--start_app", and "warm" is the new start mode.
Note that this is only useful with incremental installs, as Android clears out
any previously saved state when an APK is replaced.
--
MOS_MIGRATED_REVID=99508790
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=99224654
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=99174214
|
|
|
|
|
|
|
| |
color when the build fails.
--
MOS_MIGRATED_REVID=98736813
|
|
|
|
|
|
|
|
|
| |
wrapping it in a QueryException.
QueryException should usually indicate a persistent failure, while an InterruptedException is transient. Wrapping the InterruptedException in a QueryException just obfuscates state.
--
MOS_MIGRATED_REVID=97815388
|
|
|
|
|
|
|
|
|
|
|
| |
This involved quite a few changes, mainly changing a bunch of places where we refer to packages by a PathFragment to PackageIdentifier.
The only wart is the code in PathPackageLocator: ideally, it would just call into PackageLookupFunction. Unfortunately, it is (through globbing and Parser.include) called from within a Skyframe function, and we don't want to have two eval() calls going on at the same time, so we cannot use that.
There is a potential correctness issue there: PathPackageLocator now assumes where external repositories are put and assumes that they are there when it gets control, but my understanding is that the associated RepositoryValue is always evaluated before, so it works out okay.
--
MOS_MIGRATED_REVID=97751539
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=97648982
|
|
|
|
|
|
|
|
|
|
|
| |
This involved quite a few changes, mainly changing a bunch of places where we refer to packages by a PathFragment to PackageIdentifier.
The only wart is the code in PathPackageLocator: ideally, it would just call into PackageLookupFunction. Unfortunately, it is (through globbing and Parser.include) called from within a Skyframe function, and we don't want to have two eval() calls going on at the same time, so we cannot use that.
There is a potential correctness issue there: PathPackageLocator now assumes where external repositories are put and assumes that they are there when it gets control, but my understanding is that the associated RepositoryValue is always evaluated before, so it works out okay.
--
MOS_MIGRATED_REVID=97647787
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=96703011
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=95843033
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=95615442
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
additional information about aspect dependencies when --output is set to {xml, proto}.
One quirk of this CL is that if BUILD files of direct dependencies are added both under <subinclude> and <load>. Any better ideas are appreciated.
As a drive-by fix, if for some reason a package reports the same label as a both subinclude and a Skylark dependency, it will only be reported once in the proto output.
RELNOTES[NEW]: added --with_aspect_deps to blaze query, that prints additional information about aspects of target when --output is set to {xml, proto, record}.
--
MOS_MIGRATED_REVID=95272042
|
|
|
|
|
|
|
| |
This was omitted when the bulk of the code was moved in order not to pollute the output of "bazel help" with a useless command, but now it is in the way of testing Android functionality.
--
MOS_MIGRATED_REVID=94747309
|
|
|
|
|
|
|
|
|
| |
We prefer to focus on the web documentation instead.
RELNOTES[INC]: 'blaze doc_ext' command removed.
--
MOS_MIGRATED_REVID=93871336
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tested on Linux with the following command line:
$ bazel help info-keys | sort | uniq -c
And compared the output before and after.
Fixes #175
--
Change-Id: Ia879796abf6f5b6b5742bfc9574d64fe53a650a3
MOS_MIGRATED_REVID=93127869
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=91818123
|
|
|
|
|
|
|
|
|
|
| |
`bazel help completion` dump all options completion pattern
for each command, giving hints on the format of the completion
residue (e.g., `label`, `path`, `{a,enum}`, ...). This
dump can be used to generate completion scripts.
--
MOS_MIGRATED_REVID=90743024
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=89973895
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moves pattern resolving logic from TargetPatternFunction.Resolver to
a top level class. Adds a layer of abstraction to the Resolver
implementation enabling it to be backed by either an Environment or
a Graph, for use in SkyFunction evaluation or on-the-fly evaluation,
respectively. Finally, SkyQueryEnvironment#preloadOrThrow now checks
to see if each target pattern exists in the graph, and any that
don't will be resolved on-the-fly.
--
MOS_MIGRATED_REVID=88861201
|
|
|
|
|
|
|
|
| |
e.g.
$ bazel info bazel-bin
--
MOS_MIGRATED_REVID=87943280
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87821306
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87728012
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87717872
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87712063
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87596401
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87513766
|
|
|
|
|
|
|
| |
can be used in their stead.
--
MOS_MIGRATED_REVID=87334648
|
|
|
|
|
|
|
|
|
| |
This environment eagerly preloads the transitive closure of a specified query "universe", and so may not be as efficient as the standard query for limited-scope queries. It is activated when the universe is specified and ordered results are not requested (since it is currently unable to order results).
Tests were modified/added to exercise this environment where deemed interesting. Some ugly hacks were done to add coverage in AbstractQueryTest and friends, because currently even if the full depot is loaded (using //...), individual target patterns most likely won't be present in the graph. A better way to deal with this situation, suggested by felly, is probably to extract target pattern resolution logic to an auxiliary function so that query is able to resolve target patterns without mutating the graph, and then call into the read-only graph with the resolved patterns. That may be done in a follow-up, in which case the "scope" of every query could be //... .
--
MOS_MIGRATED_REVID=87257028
|
|
|
|
|
|
|
| |
Having an error message in path/to/package and //path/to/package resolve to //path/to/package:package was a bit strange.
--
MOS_MIGRATED_REVID=87171051
|
|
|
|
|
|
|
| |
way to test this, because no matter what I do (pipe to a FIFO, run under stdbuf), Blaze doesn't block on outputting there, so I can't interrupt and cause the exception.
--
MOS_MIGRATED_REVID=86114736
|
|
|
|
|
|
|
|
|
| |
move some utility methods to utility class.
The real goal of this CL is to make sure all users of BlazeQueryEnvironment are constructing one through EvaluableBlazeQueryEnvironment#newQueryEnvironment, and not directly. This ensures that alternate implementations of EvaluableBlazeQueryEnvironment will be automatically injected via #newQueryEnvironment.
--
MOS_MIGRATED_REVID=86112439
|
|
|
|
|
|
|
|
|
|
|
| |
BlazeQueryEnvironment that exposes an evaluateQuery method, and also implements the non-LabelVisitor-specific parts of BlazeQueryEnvironment, for other implementations' uses.
Most of the code is just a straight refactoring of BlazeQueryEnvironment into EvaluableBlazeQueryEnvironment (and BlazeTargetAccessor). Ignoring whitespace changes in [] may be your friend for seeing that it's a straight move.
This also allows us to change tests to use QueryCommand.newQueryEnvironment, in preparation for newQueryEnvironment potentially returning a different EvaluableBlazeQueryEnvironment subclass depending on the circumstances.
--
MOS_MIGRATED_REVID=86088953
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=85902304
|
|
--
MOE_MIGRATED_REVID=85702957
|