aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/analysis/mock/BazelAnalysisMock.java
Commit message (Collapse)AuthorAge
* test-wrapper: add empty impl + Bazel flagGravatar Laszlo Csomor2018-08-14
| | | | | | | | | | | | | | | | | | | | | | | This commit adds: - the skeleton implementation of the Windows native test wrapper - a depenency on the native test wrapper from test rules, through the new $test_wrapper rule attribute - the --windows_native_test_wrapper Bazel flag, which is currently a no-op See https://github.com/bazelbuild/bazel/issues/5508 Change-Id: I8df95c8ce8bab53c51c257698ec95416065a836e Closes #5854. Change-Id: I2ffc78bceec5dd867af775b5878f105fa87c3dba PiperOrigin-RevId: 208650699
* Remove support for explicitly setting java_toolchain.encoding to UTF-8Gravatar cushon2018-08-08
| | | | PiperOrigin-RevId: 207891979
* Add a flag to split test.xml generation into a separate SpawnGravatar ulfjack2018-07-27
| | | | | | | | | | At this time, this is only implemented for the StandaloneTestStrategy. This solves a race condition on Posix-like systems, where we cannot guarantee that the pipes are actually fully flushed to disk when the test process exits, and this can cause the test.xml to be empty, which makes it hard to debug issues. (The test.log files do not show up in normal CI systems, only the test.xml files.) Progress on #4608. PiperOrigin-RevId: 206292179
* Automated rollback of commit ce8f52060e2cf1e5a49a522039f0cba2a340f7e3.Gravatar cushon2018-07-25
| | | | PiperOrigin-RevId: 206102499
* Automated rollback of commit f4a3dd9b8124dc7b2795f89e6700881b66371e4f.Gravatar lberki2018-07-12
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks //devtools/blaze/integration:{[]_test_test,gdp_validation_test} and at leats //contentads/supermixer/server:supermixer . *** Original change description *** Refactor handling of API generation in JavaPluginInfoProvider Instead of keeping two copies of state for the API-generating and non-API-generating cases, create a 'JavaPluginInfo' abstraction to contain all state for each case, and then keep two copies in the top-level JavaPluginInfoProvider provider. This will make it easier and less error-prone to add additional state to the provider. PiperOrigin-RevId: 204258844
* Refactor handling of API generation in JavaPluginInfoProviderGravatar cushon2018-07-11
| | | | | | | | | | | | Instead of keeping two copies of state for the API-generating and non-API-generating cases, create a 'JavaPluginInfo' abstraction to contain all state for each case, and then keep two copies in the top-level JavaPluginInfoProvider provider. This will make it easier and less error-prone to add additional state to the provider. PiperOrigin-RevId: 204151605
* Remove support for java_runtime_suiteGravatar cushon2018-07-05
| | | | | RELNOTES: Remove support for java_runtime_suite; use alias() together with select() instead. PiperOrigin-RevId: 203393253
* Create a whitelist for android_library rules with deps but not srcsGravatar cushon2018-07-03
| | | | PiperOrigin-RevId: 203230801
* Implement LcovMerger.Gravatar elenairina2018-06-11
| | | | | | | | | | | | | | LcovMerger is a tool that merges all the intermediate lcov tracefiles (with .dat extension) found under a coverage directory and prints the merged tracefile to a given output file. A custom implementation for merging lcov tracefiles is needed because the merging functionality of lcov itself is very slow. LcovMerger is required to get a single coverage report (lcov tracefile) from a bazel coverage command that executes multiple tests. ATM LcovMerger is only invoked by tools/test/collect_coverage.sh that collects and merges the tracefiles from a single test invocation. It will also be used from a CoverageReportAction. Progress on #5246. PiperOrigin-RevId: 200054506
* Automated rollback of commit 5df8eb24f84a6943e70876c805c77f06e719dcd7.Gravatar Googler2018-06-08
| | | | PiperOrigin-RevId: 199864175
* Automated rollback of commit ccaccb2b277a82f7264567563a02ab133a0f6e6f.Gravatar jmmv2018-06-07
| | | | | | | | | | | | | | | *** Reason for rollback *** Suspected root cause behind tons of Blaze nightly failures. One example: [] *** Original change description *** Let blaze obfuscate manual main_dex_list according to proguard map. PiperOrigin-RevId: 199737371
* Let blaze obfuscate manual main_dex_list according to proguard map.Gravatar Googler2018-06-06
| | | | PiperOrigin-RevId: 199529974
* Automated rollback of commit 7fcbc8ffdead028d19606fefa2fa3be13781da98.Gravatar laszlocsomor2018-05-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** According to a post-submit regression test, this commit increased Bazel's memory usage slightly beyond some threshold. That event prompted me to consider and question the necessity of this commit. My goal is to make Bazel work on Windows without requiring MSYS, failing the build only if an action is a shell action. Toolchainifying the shell is related to, but not required by this effort. What is required is to fail the build when Bazel tries to create a shell action but the shell is missing, and we have that already with ShToolchain.getPath (which only considers the ShellConfiguration fragment). What's missing for my goal is to reimplement hardcoded shell actions (i.e. SpawnAction.builder().setShellCommand(...)) without using the shell where possible. *** Original change description *** shell toolchain: genrule now uses it genrule() now uses the shell toolchain (as well as the ShellConfiguration config fragment) to look up the shell interpreter's path. Also the CommandHelper no longer looks up the shell interpreter's path itself. Instead its ctor takes the path as an argument. This allows supporting rules that already use the shell toolchain and rules that still only consider the configuration fragment. With these changes genrule() is now able to use the shell interpreter registered as a toolchain, even if there's no `--shell_executable` flag specified (or its value is empty). Subsequent commits will migrate more and more rules to depend on the shell toolchain. This commit takes us closer to: 1. be able to detect the local shell interpreter's location, especially when it's not the default /bin/bash 2. be able to define different shell toolchains (different interpreter paths) for remote builds 3. gracefully fail the build if the machine has no shell installed but the action graph included a shell action See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 Closes #5282. *** RELNOTES: none PiperOrigin-RevId: 198527351
* shell toolchain: genrule now uses itGravatar Laszlo Csomor2018-05-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | genrule() now uses the shell toolchain (as well as the ShellConfiguration config fragment) to look up the shell interpreter's path. Also the CommandHelper no longer looks up the shell interpreter's path itself. Instead its ctor takes the path as an argument. This allows supporting rules that already use the shell toolchain and rules that still only consider the configuration fragment. With these changes genrule() is now able to use the shell interpreter registered as a toolchain, even if there's no `--shell_executable` flag specified (or its value is empty). Subsequent commits will migrate more and more rules to depend on the shell toolchain. This commit takes us closer to: 1. be able to detect the local shell interpreter's location, especially when it's not the default /bin/bash 2. be able to define different shell toolchains (different interpreter paths) for remote builds 3. gracefully fail the build if the machine has no shell installed but the action graph included a shell action See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 Closes #5282. Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 PiperOrigin-RevId: 198394021
* Replace --experimental_android_enforce_strict_deps_for_binaries_under_test ↵Gravatar cushon2018-05-15
| | | | | | with a package whitelist PiperOrigin-RevId: 196688645
* Remove BuildConfiguration.Fragment#setupActionEnvironment().Gravatar lberki2018-04-11
| | | | | | | This is accomplished by moving it to ConfiguredRuleClassProvider. This also suggests a neat way to get rid of logic in ShellConfiguration.Loader() by moving the determination of the shell executable, there, too, but not in this change. RELNOTES: None. PiperOrigin-RevId: 192411609
* Move shell executable to its own configuration fragment.Gravatar lberki2018-04-06
| | | | | RELNOTES: None. PiperOrigin-RevId: 191861074
* Remove legacy manifest merging from Bazel.Gravatar ajmichael2018-04-05
| | | | | RELNOTES: android_binary.manifest_merger is no longer supported. PiperOrigin-RevId: 191791177
* Remove Android jar from android_local_test bootclasspathGravatar ajmichael2018-04-02
| | | | | | | | | Instead, treat it as a regular compile-time library dependency. This fixes Java8 compilation in android_local_test. RELNOTES: None PiperOrigin-RevId: 191359834
* Add toolchain definitions for autoconfigured cc_toolchain entries.Gravatar jcater2018-03-27
| | | | PiperOrigin-RevId: 190611069
* Allow BazelPackageLoader to load external repositories.Gravatar carmi2018-03-13
| | | | | | | | | Also, disallow BazelPackageLoader from fetching missing external repos. Integration tests for BazelPackageLoader wrt external repos will be left for a follow-up CL. RELNOTES: None. PiperOrigin-RevId: 188967694
* Adjust Android integration testing environment by adding a dependency to theGravatar cnsun2018-02-26
| | | | | | | import_deps_checker. RELNOTES: None PiperOrigin-RevId: 187095109
* Use a separate implicit dependency for dexbuilder in proguarded android buildsGravatar kmb2018-02-21
| | | | | | RELNOTES: None. PiperOrigin-RevId: 186511953
* Remove hard-wired basenames for the test setup and the coverage collection ↵Gravatar lberki2018-02-09
| | | | | | | | | script. Accomplished by creating an explicit attribute for both of them on test actions. RELNOTES: None. PiperOrigin-RevId: 185132460
* Hooks to support core library desugaring in Android buildsGravatar kmb2018-02-07
| | | | | | RELNOTES: None. PiperOrigin-RevId: 184909685
* Stop setting annotations_jar in Bazel android_sdk.Gravatar ajmichael2018-01-26
| | | | | | | It is optional as of https://github.com/bazelbuild/bazel/commit/1a6ca6f47aef36d56b5cb2f9da114af75dde583d. RELNOTES: None PiperOrigin-RevId: 183391869
* Fold the Jvm configuration fragment into JavaConfiguration.Gravatar lberki2018-01-11
| | | | | RELNOTES: None. PiperOrigin-RevId: 181579365
* Adds a CODEC for CppConfiguration.Gravatar shahan2018-01-10
| | | | | | | * Creates an enum for cpu transformer, which is easier to serialize than an opaque function. This also means moving FakeCPU to avoid introducing a circular dependency. * Adds a CODEC to Path using InjectingObjectCodec. PiperOrigin-RevId: 181445911
* Remove code that used to support --javabase=<absolute path>.Gravatar lberki2018-01-08
| | | | | | | | | This is the first step in removing package loading from JvmConfigurationLoader (I didn't want to add the rest into this change because it's technically possible to access ctx.fragments.jvm even though it contains no fields, so removing that is an incompatible change) and it's also possible that removing error reporting from JvmConfigurationLoader causes some subtle changes in behavior. Baby steps. Now that the hard part is done, there is no need to rush. RELNOTES: None. PiperOrigin-RevId: 181143978
* Remove references to some internal tooling.Gravatar ajmichael2017-12-20
| | | | | RELNOTES: None PiperOrigin-RevId: 179722149
* Ensure that the target package in the <instrumentation> tag of the ↵Gravatar jingwen2017-12-19
| | | | | | | | | | | | instrumentation android_binary's AndroidManifest.xml references the correct package name of the instrumented android_binary. During an instrumentation test, ART will use the targetPackage specified in the instrumentation APK's AndroidManifest to determine the application to be instrumented. We can perform this check in Bazel at execution time, before the apps are loaded onto the device. See android_instrumentation_test_integration_test.sh for the e2e example. GITHUB: https://github.com/bazelbuild/bazel/issues/903 RELNOTES: None. PiperOrigin-RevId: 179564246
* Depend on //tools/jdk:host_jdk for the host javabase instead of the default JDK.Gravatar lberki2017-12-06
| | | | | RELNOTES: None. PiperOrigin-RevId: 178074510
* Support incremental dexing tools in proguarded Android buildsGravatar kmb2017-11-17
| | | | | | RELNOTES: None. PiperOrigin-RevId: 176109497
* Open source ZipFilterBuilder for android_instrumentation_testGravatar jingwen2017-11-13
| | | | | | | GITHUB: #903 RELNOTES: None. PiperOrigin-RevId: 175600267
* [Bazel] Change default place where {java,cc}_proto_library look for their ↵Gravatar carmi2017-10-20
| | | | | | | | | external repo dependencies. This fixes https://github.com/cgrushko/proto_library/issues/4. RELNOTES: [Bazel] {java,cc}_proto_library now look for dependencies in @com_google_protobuf, instead of in @com_google_protobuf_$LANG PiperOrigin-RevId: 172685722
* Add a whitelist for packages that can contain android_devices rules. ↵Gravatar ajmichael2017-10-06
| | | | | | | Currently, this whitelist includes every package. RELNOTES: None PiperOrigin-RevId: 171192613
* Use bundled proguard 5.3.3 instead of 4.7 from the SDKGravatar ajmichael2017-10-06
| | | | | | | | | Fixes https://github.com/bazelbuild/bazel/issues/3777 Also adds a proguard integration test so that hopefully we notice next time it breaks. RELNOTES: Updated Android proguard to 5.3.3. It now works with android-24+. PiperOrigin-RevId: 171162295
* Remove support for ProtocolBuffers2.Gravatar kaipi2017-10-06
| | | | PiperOrigin-RevId: 171013687
* Inject BlazeDirectories into FdoSupportFunction directly, instead of ↵Gravatar janakr2017-09-25
| | | | | | | | depending on a precomputed value. BlazeDirectories don't change over the lifetime of the Blaze server, and certainly not over the lifetime of a SkyframeExecutor instance, which already had a reference to them. The goal is getting rid of the precomputed value entirely, but since this change necessitated a fair number of testing changes, I'm mailing this out as a first step. PiperOrigin-RevId: 169705474
* Bazel now can build dynamic library from cc_libraryGravatar Yun Peng2017-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* aar_import creates res/values/empty.xml if it contains no resources.Gravatar ajmichael2017-08-29
| | | | | | | | | To do this, add a new tool that is used instead of zipper to get the resources out of the AAR. This tool creates res/values/empty.xml if there are no resources in the AAR. Also, some general cleaning of the code. RELNOTES: None PiperOrigin-RevId: 166768607
* Open source some objc tests. Most notably, proto and j2objc tests still ↵Gravatar cparsons2017-08-28
| | | | | | | remain, but will follow. RELNOTES: None. PiperOrigin-RevId: 166635306
* Remove FeaturePolicyConfiguration et al. in favor of the new Whitelisting.Gravatar mstaib2017-08-22
| | | | | | | | This migrates the config_feature_flag implementation over and removes the old flag (which was not used except to test it). Fare thee well, old flag. RELNOTES: None. PiperOrigin-RevId: 165995681
* Remove ConfigurationCollectionFactory as part of the static config cleanup.Gravatar gregce2017-08-18
| | | | PiperOrigin-RevId: 165578449
* Remove ConfigurationFactory as part of the static configuration cleanup.Gravatar gregce2017-08-17
| | | | PiperOrigin-RevId: 165478994
* Move core rules to a top-level class.Gravatar ulfjack2017-08-03
| | | | PiperOrigin-RevId: 164013246
* Remove old intellij aspect code bundled with BazelGravatar Googler2017-07-31
| | | | PiperOrigin-RevId: 163538636
* Apply native binary launcher to sh_binaryGravatar Yun Peng2017-07-31
| | | | | | | | | | | | This change: 1. Added launcher to @bazel_tools If the host platform is Windows, we use a prebuilt launcher.exe , otherwise the launcher needs to be built with MSVC first. 2. Launching sh_binary using native launcher. Change-Id: I5a63135455057fbfe04ff0cce7ec7994ef0c347a PiperOrigin-RevId: 163442540
* Make $jarjar_bin point to //tools/android:jarjar_bin.Gravatar ajmichael2017-07-24
| | | | | | | Fixes TODO in AndroidRuleClasses.java. RELNOTES: None PiperOrigin-RevId: 162955052
* Remove resource_extractor from android_sdk rule.Gravatar ajmichael2017-06-29
| | | | | | | | | | resource_extractor has nothing to do with the Android SDK. Once upon a time, it was needed for jack support, so it was colocated with the jack attributes in android_sdk. Nowadays, it is used as a necessary step before singlejar can run to build the APK. RELNOTES: None PiperOrigin-RevId: 160479247
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-09 18:03:44 +0000