| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 169428146
|
|
|
|
| |
PiperOrigin-RevId: 169418286
|
|
|
|
|
| |
Change-Id: Ia250c322353638928747d99fbfdb62808a2fd838
PiperOrigin-RevId: 169417597
|
|
|
|
| |
PiperOrigin-RevId: 169414076
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, every Android-related top-level target will use the feature
flag whitelist, regardless of whether it has any feature flags.
This change makes it so that these targets only load the whitelist if
they need it.
In the process, it moves the value of the whitelist from the attribute
definition method to outside of it. Because it's a builder, this is only
a minor change to each callsite.
RELNOTES: None.
PiperOrigin-RevId: 169405621
|
|
|
|
|
|
|
| |
This change misses the corner case of builds which are entirely 32-bit (as opposed to mixed 32&64 bit) due to no legitimate place to report the error of such a build; execution will fail for such builds at the action level.
RELNOTES: None.
PiperOrigin-RevId: 169397354
|
|
|
|
|
|
| |
TESTED=unit tests
RELNOTES: none
PiperOrigin-RevId: 169395919
|
|
|
|
| |
PiperOrigin-RevId: 169386655
|
|
|
|
|
|
| |
Fixes #3714
RELNOTES: None.
PiperOrigin-RevId: 169382686
|
|
|
|
|
|
|
|
| |
Static libraries: cc_archive -> archive
Dynamic libraries: cc_dynamic_library -> dynamic_library
RELNOTES: None
PiperOrigin-RevId: 169374373
|
|
|
|
| |
PiperOrigin-RevId: 169370539
|
|
|
|
|
|
|
|
|
|
|
| |
When copy_dynamic_libraries_to_binary is enabled, we copy the shared
libraries required by the binary to the binary's directory.
Bazel will throw errors if there are confilct actions generating the
same artifacts.
Change-Id: I09a5a599ca0ec7a67efd49d5aa89481450fa4e90
PiperOrigin-RevId: 169364498
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 169334039
|
|
|
|
|
|
|
|
| |
Also clarify the interfaces *TransitionResolver* - which determines what
transition to apply to an input configuration and *ConfigurationResolver*
- which determines the output configuration from that transition.
PiperOrigin-RevId: 169311986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR to Bazel.
After this change:
- Any files written to the TEST_UNDECLARED_OUTPUTS_DIR directory will be zipped up and added to an outputs.zip file under bazel-testlogs.
- Files will be listed in a MANIFEST file under bazel-testlogs.
- Any files written to TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR will be concatenated together into an ANNOTATIONS file under bazel-testlogs.
This provides a channel for tests to provide extra information outside of the test output itself. This is useful for things like verbose server logs.
Note: The //src/test/shell/bazel:bazel_test_test target has a pre-existing breakage (see https://github.com/bazelbuild/bazel/issues/3727). But the new tests pass.
RELNOTES: Tests can now write files to TEST_UNDECLARED_OUTPUTS_DIR and TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR and these will be reflected under bazel-testlogs.
PiperOrigin-RevId: 169282528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that the code to filter in analysis, based on android_ide_common,
isn't as strict as aapt is.
In particular, given a language filter (like 'en'), aapt rejects language and
region resources (like 'en-rUS') but android_ide_common does not.
We could try to just patch this behavior, but it's probably indicative of
larger inconsistancies between android_ide_common and aapt. As a result, always
pass resource filters to aapt. In most cases, if we already filtered in
analysis, few if any resources will be filtered out by aapt, so we'll still
keep most of the performance gains we expected from filtering in analysis.
RELNOTES: none
PiperOrigin-RevId: 169254335
|
|
|
|
|
|
| |
causes the cc_toolchain dependency of cc targets to be selected using the platforms/toolchains constraint solving system.
PiperOrigin-RevId: 169250621
|
|
|
|
|
|
|
|
|
|
| |
In general, R classes for Android libraries are used for compilation of those
libraries and then thrown away. They are replaced by the R classes from the
binary. Removing the unused android_library R classes will make binaries
smaller.
RELNOTES: none
PiperOrigin-RevId: 169244068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add recursive test_suite rules for all tests that
ci.bazel.io runs for Windows, and set the
top-level test_suite as the CI test target.
Doing so shortens the command line and works
around https://github.com/bazelbuild/bazel/issues/3742
I verified that the old set of tests are the same
as the new set.
Change-Id: Id8d5da3f0c03c9b8969a9f8e1e9a3096888365aa
PiperOrigin-RevId: 169242858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, there is no way to enforce that LateBoundDefaults only access
the fragments that they declare. This means that LateBoundDefaults can
fail to declare fragments at all, or declare the wrong ones, and still
have no troubles.
But when trimming, these fragments must be declared, because otherwise
they will not necessarily be available.
This change refactors LateBoundDefault to declare a single fragment type,
not a set. All existing LateBoundDefaults use sets with a single element
or no elements at all for their set of fragment classes, so this does not
limit anything being done currently.
To account for LateBoundDefaults which do not use configuration at all,
typically those which only want to access the configured attribute map,
it is possible for Void to be the fragment class which is requested.
To account for LateBoundDefaults which need to access methods of the
BuildConfiguration instance itself, it is possible for BuildConfiguration
to be the fragment class which is requested; however, this is unsafe, so
it is only a temporary state until a way to do this without also giving
access to all of the fragments can be added.
Drive-by refactoring: LateBoundDefaults' values are now typed. All actual
production LateBoundDefaults were Label or List<Label> typed, through the
LateBoundLabel and LateBoundLabelList subclasses. These subclasses have
been removed, and LateBoundDefault has two type parameters, one for the
type of its input, and one for the type of its output.
RELNOTES: None.
PiperOrigin-RevId: 169242278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a vexingly large world of possible option types, each with its own quirks of how it interfaces with new inputs as they come in: values can be
- overridden (default)
- concatenated (allowMultiple)
- flattened (allowMultiple that accepts list inputs)
- disappear into additional flag inputs (expansion flags)
Or some combination of the above, in the case of flags with implicit dependencies and wrapper options.
Begin removing the error-prone treatment of all option types with conditional branches. This model of the different options will make it much easier to isolate the option-type specific logic with the command-line parsing logic. Flags that affect other flags (implicit requirements, expansions, and wrappers) will be migrated in a later change.
This CL does not change flag parsing semantics, just migrates the current parsing logic to the new class structure.
RELNOTES: None.
PiperOrigin-RevId: 169239182
|
|
|
|
| |
PiperOrigin-RevId: 169234249
|
|
|
|
|
|
|
|
|
|
|
| |
Before this cl each linking and compilation action would contain a full copy of
all build variables. However, some build variables can be reused, for the
memory consumption benefit. With this cl, we contruct a Variables instance in
the CcToolchain, and make it a parent of all per-linking and per-compilation
variables.
RELNOTES: None.
PiperOrigin-RevId: 169233756
|
|
|
|
|
|
|
|
|
| |
Those files are not linked anywhere and where removed by the
export process either by accident or for better support from IntelliJ.
According to ij.bazel.build a non linked target will not be analyzed
so it should be safe.
PiperOrigin-RevId: 169229654
|
|
|
|
|
|
|
|
|
|
|
| |
There are several use cases for using full compile time jars instead of ijars (scala macros cannot use ijar, kotlin dependencies, etc). This change allows creating a provider with or without creating interface jars for compile time, exposing the right full/interface jars on target[JavaInfo].compile_jars and target[JavaInfo].full_compile_jars.
For more details see https://github.com/bazelbuild/bazel/issues/3528.
Fixes #3528
RELNOTES: java_common.create_provider is now supported with creating ijars by default. This introduces incompatibilities for existing users. Please set use_ijar=False if you don't want to use ijars.
PiperOrigin-RevId: 169222793
|
|
|
|
|
|
| |
This is a trivial change with a large file footprint.
PiperOrigin-RevId: 169169864
|
|
|
|
| |
PiperOrigin-RevId: 169163737
|
|
|
|
|
|
|
|
|
| |
tests fails, we still want to be able to download the logs and other outputs from CAS.
This fixes a bug introduced by https://github.com/bazelbuild/bazel/commit/562fcf9f5dfd14daea718f77da95b43b1400689b. To reproduce: run a failing test vs a BES service, the test log would not be uploaded.
TESTED=unit tests
PiperOrigin-RevId: 169143428
|
|
|
|
| |
PiperOrigin-RevId: 169116918
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, they assumed android-25 but Bazel CI does not have android-25
installed. In practice, these tests do not care which version is used so we
should use //tools/android:defaults_jar which selects the jar based on the
configuration. However, that target does not produce the jar as a runfile, it
is only useful currently for neverlink compilation.
RELNOTES: None
PiperOrigin-RevId: 169104539
|
|
|
|
| |
PiperOrigin-RevId: 169101689
|
|
|
|
| |
PiperOrigin-RevId: 169087881
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the classpath is too long, the launcher creates a jar file to pass
the classpath value. This change makes the jar file's name random.
It fixed the bug that when running multiple instances of the same java binary,
they all try to create the same classpath jar file. For example, when
running java_test with shard_count > 1.
Also, we delete the classpath jar file after the program finishes, so
that we don't leave any garbages behind.
Change-Id: I67926b3ef76dcb1806797e977ecaa7c6763c5cf2
PiperOrigin-RevId: 169087032
|
|
|
|
|
|
|
|
|
| |
...by quoting the delimiter of the here-documents, instead of the
documents themselves. This is possible as the here-documents are
constants in that test (not depending on the test setup).
Change-Id: If272060ce9f6384821e4bd0bd9033925bd1efe9c
PiperOrigin-RevId: 169080394
|
|
|
|
|
|
|
|
|
|
| |
When printing envvars, use "${FOO:-}" instead of
"${FOO}", so the test won't fail if an envvar is
undefined.
See https://github.com/bazelbuild/bazel/issues/3618
PiperOrigin-RevId: 169059836
|
|
|
|
|
|
| |
Makes it easier to do Skylark param file support which uses a format string.
PiperOrigin-RevId: 169019600
|
|
|
|
|
|
|
| |
Exempt RuleConfiguredTarget in this change because that's liable to touch
a billion files.
PiperOrigin-RevId: 168929827
|
|
|
|
|
|
| |
This also migrates the example to the new rules_apple ios_application rule, since the native Bazel rule is being deleted.
PiperOrigin-RevId: 168902357
|
|
|
|
|
|
|
| |
first.
Change-Id: I3d78418d2c51d09e3862fbab1854ae73a0b3253c
PiperOrigin-RevId: 168889865
|
|
|
|
| |
PiperOrigin-RevId: 168883984
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 168862724
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We get UnparsedValues after ... parsing the options. So that doesn't
make sense. What was meant was that it wasn't converted to the final
value.
In an effort to make this distinction more clear, this change will
make the terminology more consistent. The `--foo=bar` step is
"parsing" and the `bar -> Object` step is "converting" (it is, in
fact, done by Converters).
RELNOTES: None.
PiperOrigin-RevId: 168852847
|
|
|
|
|
|
|
| |
But not for Bazel because of #3719
RELNOTES: None
PiperOrigin-RevId: 168836686
|
|
|
|
| |
PiperOrigin-RevId: 168835640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks clang_tidy.
*** Original change description ***
Introduce -c source_file -o output_file build variables
Prior to this cl CompileCommandLine would (almost) unconditionally emit -c and
-o flags. This cl removes this logic and relies on crosstool to emit these
flags. This is another small step towards platform independent C++ rules.
Memory use is not affected, since the build variables used by this cl are already
exposed, this cl just forces crosstools to use it.
RELNOTES: None.
PiperOrigin-RevId: 168834576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Working towards: https://github.com/bazelbuild/bazel/issues/3311
When building dynamic library on Windows, Bazel builds an import library
and a DLL.
Bazel provides a feature called windows_export_all_symbols, if this
feature is enabled(and no_windows_export_all_symbols is not) for a
cc_library, then Bazel parses object files of that cc_library to generate
a DEF file that will be used during linking time to export symbols from
DLL. This feature can be specified at crosstool, package, target and
command line level.
A few differences from Unix platforms:
1. We don't build the shared library on Windows by default, users have to
specifiy --output_groups=dynamic_library for building dynamic libraries.
This output group is also available on other platforms.
2. By default, cc_test is dynamically linked on Unix, but it will be
statically linked on Windows by default. (meaning the default value of
linkstatic in cc_test is 1 on Windows, and 0 on other platforms)
3. For global data symbols, __declspec(dllimport) must still be used in
source files.
Remaining issues:
1. Extensions for import library and DLL are not correct yet.
2. DLLs are not guaranteed to be available during runtime yet.
3. Diamond problem
If a cc_library A is specified as linkstatic=0, then no dynamic library
will be built for it, so if another cc_library B depends on it, A will
be statically linked into B, and if a cc_binary C depends on B, A will
also be statically linked into C and B will be dynamically linked to C.
This is wrong because A is duplicated in both B and C.
It is essentially a diamond problem describled in C++ Transitive Library.
(https://docs.google.com/document/d/1-tv0_79zGyBoDmaP_pYWaBVUwHUteLpAs90_rUl-VY8/edit?usp=sharing)
Hopefully, we can avoid this by using cc_shared_library rule in future.
Change-Id: I23640d4caf8afe65d60b1522af6368536d7a8408
PiperOrigin-RevId: 168829958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel building itself on FreeBSD, also #3739.
*** Original change description ***
Introduce empty "toolchain_category" rule for labels that will be used as
categories of toolchains for the purpose of toolchain selection.
Up to now, we've used the native toolchain_type rule for this purpose. That rule depends on a number of configuration fragments that supply build variables - we don't want toolchains to need to depend on those fragments as well. E.g. toolchain_type depends on JvmConfiguration, but we would like toolchains to work with --experimental_disable_jvm.
PiperOrigin-RevId: 168810566
|
|
|
|
| |
PiperOrigin-RevId: 168802886
|
|
|
|
|
|
| |
This is necessary for the upcoming Skylark implementation of param files.
PiperOrigin-RevId: 168744486
|