| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
| |
When reporting the completion of a target specified by an alias,
report the label of the alias, not that of the target being aliased
to.
Change-Id: If8416ceef73b01b7531ffa0012251f25a4e9f062
PiperOrigin-RevId: 170466076
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/3618
Change-Id: I1533088d4d51dc0510de5cd5b392edec95458057
PiperOrigin-RevId: 170458069
|
|
|
|
|
|
|
|
|
| |
This is so other packages can depend on them without violating our style guide. (Dependencies on test/ packages should be limited to aggregating test suites.)
The target is also renamed from ".../serialization:serialization-test-base" to a new subpackage, ".../serialization/testutils:testutils".
RELNOTES: None
PiperOrigin-RevId: 170426906
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 170418147
|
|
|
|
|
|
| |
(without affecting other uses of singlejar)
PiperOrigin-RevId: 170411730
|
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 170379445
|
|
|
|
|
|
|
| |
apple_static_library.
RELNOTES: apple_binary and apple_static_library no longer support compilation attributes such as 'srcs'. If this breaks any existing targets, you may migrate all such attributes to a new objc_library target and depend on that objc_library target via the 'deps' attribute of apple_binary or apple_static_library.
PiperOrigin-RevId: 170373794
|
|
|
|
|
|
|
| |
The old field is the error on Operation proto. The new field is the ExecuteResponse status field.
Note that the new field will also allow us to fetch logs for timing out tests, resolving a TODO, but this is not yet done is this change.
PiperOrigin-RevId: 170370676
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`depset` constructor has new arguments, `direct` and `transitive`.
`items` argument is deprecated and after its removal `direct` will
become a sole positional argument.
If `transitive` and `items` are specified, `items` must be a list of
direct elements.
In the absence of `transitive` the value of `items` can also be a
depset, but that behavior is deprecated.
RELNOTES: New depset API
PiperOrigin-RevId: 170346194
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 170343759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now Bazel can also export symbols when building dynamic library from
cc_binary.
The interface library generated can be accessed by interface_library output group.
The DEF file can still be accessed by def_file output group even when
windows_export_all_symbols feature is not specified. This is useful when
users want to filter symbols in DEF file before using it, for example,
working around the 64K symbols number limit.
Change-Id: I5b4dae0840e20037c00d500181c40b5faedfdcd8
PiperOrigin-RevId: 170330409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks coverage for android_test (N/A).
Can be reproduced with unknown commit.
*** Original change description ***
Rollforward change of Java coverage logic.
RELNOTES: None.
*** Original change description ***
Automated rollback of commit 8d6fc64b18c7e35b93f5c43dae1dbd2f8cae2147.
PiperOrigin-RevId: 170322801
|
|
|
|
|
|
|
| |
default in AndroidConfiguration.
RELNOTES: android_library targets are no longer allowed to use deps to export targets implicitly; please use android_library.exports instead.
PiperOrigin-RevId: 170243241
|
|
|
|
|
|
|
| |
Fixes #3827.
Change-Id: Ie51650a3df6f40d2aa2c3ec016c00c98ce18c3de
PiperOrigin-RevId: 170237678
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not attempting to fix b/65618333 here, just handling one case
currently breaking users (JavaInfo created via java_common.compile).
My temporary workaround attempt to expose this information in the
soy custom rule failed (unknown commit) -- to fix users we really
need java_common changes.
RELNOTES: Expose output jars and jdeps in java_common.provider, when available.
PiperOrigin-RevId: 170236096
|
|
|
|
|
|
|
| |
resolution is used, use these attribute values to choose a CToolchain from
--crosstool_top instead of --compiler and --glibc.
PiperOrigin-RevId: 170217186
|
|
|
|
|
|
|
|
| |
Multiple tests can be specified in the same file.
An expected error (regex) can be specified in the test.
RELNOTES: None.
PiperOrigin-RevId: 170204356
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 170203679
|
|
|
|
| |
PiperOrigin-RevId: 170200236
|
|
|
|
|
|
|
| |
...as part of the TargetComplete message.
Change-Id: I8aa321a2810c3926db943f32cb1811a169e34dd7
PiperOrigin-RevId: 170171458
|
|
|
|
| |
PiperOrigin-RevId: 170121049
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If setting flag --use_new_category_enum, group the options by the new categories in both the command line output and the "everything-as-html" output used for the generated docs at https://bazel.build/versions/master/docs/command-line-reference.html. In the html output, the effect and metadata tags are listed for each option, with links to their descriptions at the bottom of the page. The tags only appear in the terminal output in -l/--long/--help_verbosity=long, and only the names appear.
This is still experimental as the majority of options do not yet use the new categorization system. The new output can be seen in command-line-reference.html format by adding the new flag to the "help everything-as-html" line in //src/main/java/com/google/devtools/build/lib:gen_command-line-reference.
The html output is in the same order as before (by blaze rule, with inherited options not repeated), which means it still has duplicate options, that should ideally be fixed separately. I propose either dropping the high-level grouping and just grouping the options by documentation category, or potentially grouping them by optionsbase in some non-class-naming way, and listing the commands that they apply to, as more and more optionsbases are used by multiple commands without being inherited (for example, all BuildEventServiceOptions are listed 20 times). People probably use ctrl-f to navigate this page anyway. Once we know that we only list each option once, we can actually have links to the options, which will make it possible to have links in the expansion lists.
Issue #3758
RELNOTES: added experimental --use_new_category_enum to the help command to output options grouped by the new type of category.
PiperOrigin-RevId: 170116553
|
|
|
|
|
|
|
|
|
|
|
| |
This CL captures the BUILD files and macro callers of native.android_library which use deps without srcs or local resources (exports_manifest, assets_dir, resource_files, etc). Using deps to implicitly export targets will be deprecated soon; please use android_library.exports instead.
Follow-up CL to this LSC by brendandouglas@: https://docs.google.com/document/d/1h2ay0i9Tyun6rJ3a7cFT3YrMar9qYoCEv9dZ_pXOSzY
LSC timeline:[]
RELNOTES: None.
PiperOrigin-RevId: 170090131
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 170088757
|
|
|
|
|
|
|
| |
Ideally, the canonical form we output from OptionUtils would be the same as for the command canonicalize-flags, but that must wait for dependencies to be cleaned up. Still, in the meantime, keep the --foo=1 normalization of --foo, and apply it to all other boolean flag values (t,true,yes,y, and false equivalents), so that the canoncalize-flags output is more canonical, even if it isn't using the --[no]foo form yet.
RELNOTES: Boolean flag values will now get normalized to 1 or 0 in canonicalize-flags output.
PiperOrigin-RevId: 170084599
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
android_ndk_repository() for testing invalid directory path attributes, and improve error descriptiveness.
Moved AndroidRepositoryUtils logic into an abstract AndroidRepositoryFunction that Android{S,N}dkRepositoryFunction extends from.
Examples of error messages:
1) Invalid NDK path
ERROR: Analysis of target '//examples/android/java/bazel:hello_world' failed; build aborted: in target '//external:android/crosstool': no such package '@androidndk//': Could not read RELEASE.TXT in Android NDK: /tmp/RELEASE.TXT (No such file or directory) Unable to read the Android NDK at /tmp, the path may be invalid. Is thepath in android_ndk_repository() or ANDROID_NDK_HOME set correctly? If the path is correct, the contents in the Android NDK directory may have been modified. Please remove the NDK and download it again with the Android SDK manager.
2) Invalid SDK path
ERROR: Analysis of target '//examples/android/java/bazel:hello_world' failed; build aborted: no such package '@androidsdk//com.android.support': Expected directory at /tmp/platforms but it is not a directory or it does not exist. Unable to read the Android SDK at /tmp, the path may be invalid. Is the path in android_sdk_repository() or ANDROID_HOME set correctly? If the path is correct, the contents in the Android SDK directory may have been modified. Please remove the SDK and download it again with the Android SDK manager.
GITHUB: #3740
RELNOTES: None.
PiperOrigin-RevId: 170068567
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 170064410
|
|
|
|
|
|
|
|
|
| |
- Make regexp to look for more strict; 'success' is too generic
a keyword as it also matches the UI output 'Build did NOT complete successfully'.
- Do not rely on backticks throwing away trailing carriage returns; mask them instead.
PiperOrigin-RevId: 170063590
|
|
|
|
|
|
|
|
| |
As a bonus, this brings in a bunch of new unit tests for the
ActionCacheChecker.
RELNOTES: None.
PiperOrigin-RevId: 170059577
|
|
|
|
|
|
|
| |
them to be created.
RELNOTES: None.
PiperOrigin-RevId: 170058295
|
|
|
|
|
|
|
|
|
| |
Instead of relying on a character-by-character StringTrie, segment paths based on PathFragments. This means UnionFS can accept any path that Bazel stores internally, removing the ASCII limitations.
This also means removing the ability to have a filesystem bound for sub-PathFragments, /foo/barbar, /foo/barqux could have the same filesystem bound at /foo/bar. This feature was tested for when a use case was envisioned, but it was never used, so removing it is safe.
RELNOTES: None.
PiperOrigin-RevId: 170054656
|
|
|
|
|
|
|
| |
Move the nested Exception classes to top-level classes, remove unused
functionality and move functionality only used in one place to that place.
PiperOrigin-RevId: 170041246
|
|
|
|
|
|
|
|
|
|
| |
RELNOTES: None.
*** Original change description ***
Automated rollback of commit 8d6fc64b18c7e35b93f5c43dae1dbd2f8cae2147.
PiperOrigin-RevId: 170038845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
)
Currently, "bazel build :script" constructs the
bazel-bin/python-prog.runfiles tree.
We'd like to do anyway with this behavior but doing so is a
backwards-incompatible change. To facilitate a transition, this CL
adds an option --experimental_build_transitive_python_runfiles to
control the behavior. In the example above, "bazel build
--noexperimental_build_transitive_python_runfiles :script" won't
construct bazel-bin/python-prog.runfiles.
Change-Id: If4d5a84c956a0bbac9067dcf38a00e5732c450f2
PiperOrigin-RevId: 170038245
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL doesn't fix all of the problems. The end location of blocks
after an if, elif, else and for is still wrong. (I added TODOs for them)
The latter is not easy to fix: One might think that one could just
set the end location of a block to the end location of the last
statement. However, if the last statement is a "pass" statement,
this is not preserved in the AST, in particular, there's no location
for it. In the future, we probably want to preserve "pass" statements.
RELNOTES: none
PiperOrigin-RevId: 170028466
|
|
|
|
| |
PiperOrigin-RevId: 170022924
|
|
|
|
|
|
|
|
|
| |
as it was not part of a valid junit xml schema.
To cherry-pick for #3286.
RELNOTES: None.
PiperOrigin-RevId: 170022796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to replace using USE_DYNAMIC_CRT env variable to configure
msvcrt linking in CROSSTOOL.
If user applies static_link_msvcrt feature to a specific target,
Bazel will choose the correct options for statically linking msvcrt.
If static_link_msvcrt is not specified, Bazel uses options for dynamically linking
msvcrt by default.
https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Change-Id: Ia078dfb528de9ffdd8a11d392db9eb3f34463b09
PiperOrigin-RevId: 170021927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--plugin, though once used for C++, is currently a Java-specific flag.
--plugin_copt is currently a total no-op, and has been for a long time.
Moving these to the Java fragment is a little neater and helps get one
step closer to enforcing LateBoundDefault fragment access.
Additionally, since the "no plugins with duplicate names" restriction
was added to work with plugin_copt, this restriction can be lifted.
It no longer adds any value.
RELNOTES: None.
PiperOrigin-RevId: 169981221
|
|
|
|
| |
PiperOrigin-RevId: 169972686
|
|
|
|
|
|
| |
and error-checking for their existence is already done by the client.
PiperOrigin-RevId: 169966701
|
|
|
|
|
|
|
|
| |
Include the coverage data file into the list of files repeorted in the
test_result event in the BEP.
Change-Id: Ia7b653addd5589268ce919b3e0349371dbc18bf2
PiperOrigin-RevId: 169956864
|
|
|
|
|
|
|
|
|
|
|
|
| |
precomputed value. Instead, manually check if the value has changed, and if it has, invalidate its consuming WorkspaceStatusValue node, forcing its re-evaluation, where it will pick up the new value.
This seems more awkward than the original code, but it is more correct in spirit: injecting a precomputed value which can change even while the source state does not is a smell. Long-term, the key for the WorkspaceStatusValue should incorporate a hash of the action, and that hash should be in the configuration, just as other configuration flags are. That isn't possible right now just because we don't have configuration trimming, and we drop all nodes on configuration changes, so putting workspace status options into the configuration would lose change pruning whenever we changed workspace status options.
If/when those problems are fixed, we can extend this change to have WorkspaceStatusFunction continue to request the action out-of-band, but keyed by the hash. Then we can stop invalidating stale nodes.
See also https://github.com/bazelbuild/bazel/issues/3785.
PiperOrigin-RevId: 169947071
|
|
|
|
| |
PiperOrigin-RevId: 169942209
|
|
|
|
| |
PiperOrigin-RevId: 169938521
|
|
|
|
| |
PiperOrigin-RevId: 169930643
|
|
|
|
| |
PiperOrigin-RevId: 169916427
|
|
|
|
|
| |
Change-Id: I64202a318bb352c2b473f3570243f545ab9fbdc1
PiperOrigin-RevId: 169913876
|
|
|
|
|
|
|
|
|
|
| |
Set no_windows on all tests that have quoted jvm_flags. Remove no_windows from
some platform-independent unit tests.
Fixes https://github.com/bazelbuild/bazel/issues/3794
RELNOTES: None
PiperOrigin-RevId: 169909924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
such as from /etc/bazel.bazelrc.
Fixes https://github.com/bazelbuild/bazel/issues/3727.
This should not be the final fix. There are remaining issues:
- This test should pass regardless of the UI used (either fix the experimental UI or fix the test to make fewer assertions).
- Outside bazelrcs should not pollute the test.
But this fixes the breakage.
RELNOTES: N/A
PiperOrigin-RevId: 169906770
|