aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/tools
Commit message (Collapse)AuthorAge
...
* Enable android dependency checking in Bazel.Gravatar xingao2018-06-29
| | | | | RELNOTES: None. PiperOrigin-RevId: 202644613
* Add virtual destructor and override to BinaryLauncherBase and subclassesGravatar Loo Rong Jie2018-06-28
| | | | | | | | | | Class with virtual functions must have virtual destructor. Subclasses should annotate overriden functions as `override`. Found by Clang's `-Winconsistent-missing-override`. Closes #5474. PiperOrigin-RevId: 202445230
* runfiles libraries: fix tests and commentsGravatar Laszlo Csomor2018-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | - Update all runfiles libraries to have the same header comment format, including the build rule to depend on the namespace / header / module to import - Fix runfiles_test.cc to include the right files (recent refactoring commit has split src/main/cpp/util/path.cc from file_[platform].cc) - Change exported variable _rlocation_isabs_pattern in runfiles.bash to be upper-case, so it is visibly a variable and not a function. See https://github.com/bazelbuild/bazel/issues/4460 Change-Id: I17e18308506ab9f5c9f410ef6bc6b9df912d42a9 Closes #5481. Change-Id: I17e18308506ab9f5c9f410ef6bc6b9df912d42a9 PiperOrigin-RevId: 202291629
* Replace //tools/defaults:jdk to //tools/jdk:*Gravatar dbabkin2018-06-26
| | | | | | | As //tools/defaults will be deprecated soon. All usages of //tools/defaults:jdk and //tools/defaults:java_toolchain should be replaced by corresponding targets in //tools/jdk/BUILD package RELNOTES:none PiperOrigin-RevId: 202114489
* Windows: Native launcher now works with unicode.Gravatar Yun Peng2018-06-25
| | | | | | | | | | | | | | The native launcher can now launch Java and Bash binary in directory with non-English characters. Unfortunately, python doesn't support running python zip file under directory with non-English characters. eg. python ./??/bin.zip will still fail. See https://github.com/bazelbuild/bazel/issues/4473 Change-Id: I77fe9cdaabffc2e0d25c7097da5c0c9333a9c4a3 PiperOrigin-RevId: 201939391
* Move HashFunction out of FileSystem, and turn it into a class, instead of an ↵Gravatar ccalvarin2018-06-21
| | | | | | | | | enum. Now that we aren't using enum names for the hash functions, we also accept the standard names, such as SHA-256. RELNOTES: None. PiperOrigin-RevId: 201624286
* Fail when resources use invalid java identifiers.Gravatar corysmith2018-06-15
| | | | | RELNOTES:None PiperOrigin-RevId: 200766836
* Adding a tool to parse the execution logs.Gravatar olaola2018-06-15
| | | | | | | | For now, the tool simply displays the log as text. TESTED=ran it RELNOTES: A tool to parse the Bazel execution log. PiperOrigin-RevId: 200718299
* Remove usage of COMPILER_MSVC in Bazel and ijarGravatar Loo Rong Jie2018-06-11
| | | | | | | | | | | | | Convert most `COMPILER_MSVC` to `_WIN32` (as they apply to Windows platform, not MSVC compiler). Only `src/tools/singlejar/zip_headers.h` and `src/main/cpp/util/md5.h` actually need `_MSC_VER`. `COMPILER_MSVC` in `third_party/protobuf` are not removed. They can be fixed by updating dependency to newer version. /cc @meteorcloudy Closes #5350. Change-Id: Ibc131abfaf34a0cb2bd338549983ea9d28eaabfe PiperOrigin-RevId: 200019793
* [launcher] Don't pass std::string to C varargs functionGravatar Loo Rong Jie2018-06-07
| | | | | | | | | | | | | `die` passes parameters to `vfprintf`. Passing `std::string` to this function might crash the program. Found by Clang on Windows. /cc @meteorcloudy Closes #5339. Change-Id: Iff7aa766770771262f91990774ff4d8de1fbeb5c PiperOrigin-RevId: 199630717
* Move path-manipulation functions to own library file.Gravatar ccalvarin2018-06-05
| | | | | | | | | | | Leave functions that make file accesses in the file library, and general blaze utilities in the blaze_util file, but move the functions that boil down to string manipulation and path formatting to their own file. (With the exception of getCWD, since absolute path syntax is relevant here.) Doing this largely to consolidate all Windows path control into a single place, so that it's easier to notice inconsistencies. For instance, ConvertPath currently makes Windows paths absolute, but not Posix paths, and MakeAbsolute relies on this behavior. In addition, JoinPath assumes Posix path syntax, which leads to some odd looking paths. These will be fixed in a followup change. (Found these issues while working on #4502, trying to fix the windows-specific system bazelrc.) RELNOTES: None. PiperOrigin-RevId: 199368226
* remote: concurrent blob downloads. Fixes #5215Gravatar buchgr2018-06-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces concurrent downloads of action outputs for remote caching/execution. So far, for an action we would download one output after the other which isn't as bad as it sounds as we would typically run dozens or hundreds of actions in parallel. However, for actions with a lot of outputs or graphs that allow limited parallelism we expect this change to positively impact performance. Note, that with this change the AbstractRemoteActionCache will attempt to always download all outputs concurrently. The actual parallelism is controlled by the underlying network transport. The gRPC transport currently enforces no limits on the concurrent calls, which should be fine given that all calls are multiplexed on a single network connection. The HTTP/1.1 transport also enforces no parallelism by default, but I have added the --remote_max_connections=INT flag which allows to specify an upper bound on the number of network connections to be open concurrently. I have introduced this flag as a defensive mechanism for users who's environment might enforce an upper bound on the number of open connections, as with this change its possible for the number of concurrently open connections to dramatically increase (from NumParallelActions to NumParallelActions * SumParallelActionOutputs). A side effect of this change is that it puts the infrastructure for retries and circuit breaking for the HttpBlobStore in place. RELNOTES: None PiperOrigin-RevId: 199005510
* Format all bzl files with buildifierGravatar vladmos2018-06-01
| | | | | | This CL aslo enables a presubmit check for correct formatting of all bzl files in //third_party/bazel. PiperOrigin-RevId: 198857055
* Improve DependencyAndroidData VALID_REGEX's robustness.Gravatar jingwen2018-05-31
| | | | | | | | | | | | | | This prevents an invalid flag like `resources:assets:AndroidManifest.xml:::local.bin` to match, as with the case in https://github.com/bazelbuild/bazel/issues/5214 where the R.txt file is missing (shouldn't happen, but let's be defensive) Error message: ``` .. invalid DependencyAndroidData: bazel-out/android-armeabi-v7a-fastbuild/bin/external/androidsdk/com.android.support/_aar/unzipped/resources/support-compat-25.0.0/res:bazel-out/android-armeabi-v7a-fastbuild/bin/external/androidsdk/com.android.support/_aar/unzipped/assets/support-compat-25.0.0/assets:bazel-out/android-armeabi-v7a-fastbuild/bin/external/androidsdk/com.android.support/support-compat-25.0.0_processed_manifest/AndroidManifest.xml:::bazel-out/android-armeabi-v7a-fastbuild/bin/external/androidsdk/com.android.support/support-compat-25.0.0_symbols/local.bin is not in the format 'resources[#resources]:assets[#assets]:manifest:r.txt(:symbols.zip?):symbols.bin' ``` RELNOTES: None. PiperOrigin-RevId: 198724816
* Turn on pseudo locale generation for compilation.Gravatar corysmith2018-05-30
| | | | | RELNOTES: android_binary.aapt_version='aapt2' now supports en_XA and ar_XB PiperOrigin-RevId: 198555305
* Use independently passed assets in aapt2 packaging as wellGravatar asteinb2018-05-29
| | | | | | | | | | | | | | Much earlier, I made a change that allowed passing assets without resources to aapt packaging. Do the same for aapt2 packaging too. The busybox seems to be expecting compiled symbols, so compile assets and pass the compiled version in. (Compiling assets doesn't save any time, but doesn't cost much either, and means that we'll eventually be able to phase out the parsed form entirely. Adapting the Busybox to take parsed assets would probably work too, but getting the code to handle it would be really messy.) RELNOTES: none PiperOrigin-RevId: 198417111
* tolerate missing outer classes for interface desugaringGravatar kmb2018-05-24
| | | | PiperOrigin-RevId: 197946783
* Send Aapt2Exception message to the logger.Gravatar jingwen2018-05-21
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, if there are non-suppressed errors during aapt2 processing, Bazel does not print them. This helps with debugging https://github.com/bazelbuild/bazel/pull/5222 With this, I get: ``` ERROR: /usr/local/google/home/jingwen/code/android_scratch_project/examples/android/java/bazel/BUILD:16:1: Processing Android resources for //examples/android/java/bazel:hello_world failed (Exit 1) May 21, 2018 5:31:01 PM com.google.devtools.build.android.ResourceProcessorBusyBox main SEVERE: java.io.IOException: Is a directory Target //examples/android/java/bazel:hello_world failed to build ``` instead of just: ``` ERROR: /usr/local/google/home/jingwen/code/android_scratch_project/examples/android/java/bazel/BUILD:16:1: Processing Android resources for //examples/android/java/bazel:hello_world failed (Exit 1) Target //examples/android/java/bazel:hello_world failed to build ``` RELNOTES: None. PiperOrigin-RevId: 197493881
* Enable proguarded Android builds with --experimental_desugar_java8_libs in BazelGravatar kmb2018-05-16
| | | | | | RELNOTES: Bazel supports including select Java 8 APIs into Android apps targeting pre-Nougat Android devices with --experimental_desugar_java8_libs PiperOrigin-RevId: 196833987
* Remove swiftstdlibtoolwrapperGravatar thomasvl2018-05-14
| | | | | | | It is a left over from long ago, and nothing should be using it as the swift support is now via skylark rules and no longer native code. PiperOrigin-RevId: 196541787
* Windows, Java launcher: Support jar files under different drivesGravatar Yun Peng2018-05-14
| | | | | | | | | Create junctions to jar's directory when java launcher and its jar are under different drives Fixed https://github.com/bazelbuild/bazel/issues/5135 Change-Id: I21c5b28f5f36c1fe234f8b781fe40d526db846cc PiperOrigin-RevId: 196477704
* Remove references to internal targetsGravatar ulfjack2018-05-14
| | | | PiperOrigin-RevId: 196476639
* Set Locale to English when uppercasing strings to match EnumsGravatar Jingwen Chen2018-05-11
| | | | | | | | | | | | | | | | | Fixes https://github.com/bazelbuild/bazel/issues/5157 If a user's default system locale is not `en`, `en_US` or `en_UK`, there may be a chance that `String#toUpperCase` will result in a string that does not exist in the Enum declaration. This is the case in #5157. To fix this, it's either 1) setting the Locale in the individual `toUpperCase` calls or 2) set Locale to English by default from `Bazel.java`. I chose the first because it seemed less intrusive, but I'm open to suggestions. Closes #5184. PiperOrigin-RevId: 196261078
* Automated rollback of commit feeccd8c0a5d97493cabfeb9481cf6f3800b9b84.Gravatar corysmith2018-05-10
| | | | | | | | | | | | | | | | | *** Reason for rollback *** Rolling forward with correct handling for pseudo locale generation flags *** Original change description *** Only include generated resources when pseudo locales are asked for. CompileResources: generate pseudo locales into a separate compiled resource file when the pseudo locale flag is true and the locale is default (e.g. absent). The generated resources must be first in the returned list of compiled resource paths. This allows the user to define custom values to the pseudo locales (which, for some obscure reason, is accepted as a reasonable practice by aapt{,2}) AndroidResourceOutputs: record the type of compiled resource in the comment field of the zip entry for fast comparison. ResourceLinker: only include the generated resources when the pseudo locale is explicitly asked for. It's important to note that the ordering for compiled resources in the zip goes <generated>...<normal>...<default>. This means the default locale will overwrite the generated locale values. Annoying, but necessary, as that is current order before introducing this cl. RELNOTES:None PiperOrigin-RevId: 196159094
* Internal changeGravatar Googler2018-05-10
| | | | PiperOrigin-RevId: 196113268
* Only include generated resources when pseudo locales are asked for.Gravatar corysmith2018-05-10
| | | | | | | | | CompileResources: generate pseudo locales into a separate compiled resource file when the pseudo locale flag is true and the locale is default (e.g. absent). The generated resources must be first in the returned list of compiled resource paths. This allows the user to define custom values to the pseudo locales (which, for some obscure reason, is accepted as a reasonable practice by aapt{,2}) AndroidResourceOutputs: record the type of compiled resource in the comment field of the zip entry for fast comparison. ResourceLinker: only include the generated resources when the pseudo locale is explicitly asked for. It's important to note that the ordering for compiled resources in the zip goes <generated>...<normal>...<default>. This means the default locale will overwrite the generated locale values. Annoying, but necessary, as that is current order before introducing this cl. RELNOTES:None PiperOrigin-RevId: 196111843
* Generate a separate psuedo locale .flat file only for default locale on ↵Gravatar corysmith2018-05-08
| | | | | | | values resources. RELNOTES:None PiperOrigin-RevId: 195821595
* Add absolute path handling to Rlocation implementation used for remote ↵Gravatar Googler2018-05-07
| | | | | | | | | | | | | execution on Windows from Java launcher. Previously the test case would fail because it tried to run a path like this: C:/temp/build-1dad9dd4-ee96-40c5-b551-c8ae12461e45/bazel-out/x64_windows-fastbuild/bin/foo/foo_test.exe.runfiles/C:/openjdk/bin/java.exe Passing presubmit: https://buildkite.com/bazel/google-bazel-presubmit/builds/2558#b83dbc25-d9ad-4d49-8f78-cde9d6810741 RELNOTES: N/A PiperOrigin-RevId: 195675424
* Extract Qualifiers class for reuse.Gravatar corysmith2018-05-07
| | | | | | | | | | | | Also, introduce caching for duplicated qualifiers. Rolling Forward: Fixed attempting to parse non-resource directories with dashes as resource directories. Added test for this case. RELNOTES: None PiperOrigin-RevId: 195658978
* Internal changeGravatar Googler2018-05-03
| | | | PiperOrigin-RevId: 195321054
* Extract Qualifiers class for reuse.Gravatar corysmith2018-05-03
| | | | | | | Also, introduce caching for duplicated qualifiers. RELNOTES:None PiperOrigin-RevId: 195313195
* Allow banning symlink action outputs from being uploaded to a remote cache.Gravatar Benjamin Peterson2018-05-03
| | | | | | | | | | | | | | | | | | | This is mostly a roll-forward of 4465dae23de989f1452e93d0a88ac2a289103dd9, which was reverted by fa36d2f48965b127e8fd397348d16e991135bfb6. The main difference is that the new behavior is now gated behind the --noremote_allow_symlink_upload flag. https://docs.google.com/document/d/1gnOYszitgrLVet3sQk-TKGqIcpkkDsc6aw-izoo-d64 is a design proposal to support symlinks in the remote cache, which would render this change moot. I'd like to be able to prevent incorrect cache behavior until that change is implemented, though. This fixes https://github.com/bazelbuild/bazel/issues/4840 (again). Closes #5122. Change-Id: I2136cfe82c2e1a8a9f5856e12a37d42cabd0e299 PiperOrigin-RevId: 195261827
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-02
| | | | PiperOrigin-RevId: 195100670
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-02
| | | | PiperOrigin-RevId: 195100125
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-02
| | | | PiperOrigin-RevId: 195094385
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-01
| | | | PiperOrigin-RevId: 195040539
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-01
| | | | PiperOrigin-RevId: 194985259
* Avoid failing when a fixed locale conflicts with a provided locale qualifer ↵Gravatar corysmith2018-05-01
| | | | | | | | | for resources. Refactor: Move the resource compilation out of the treewalk. RELNOTES: None PiperOrigin-RevId: 194982664
* Move BazelLibrary from syntax/ to packages/Gravatar brandjon2018-05-01
| | | | | | | | | This helps the Skylark interpreter to not depend on Bazel concepts, though it adds a temporary dependency of Skylint on packages/. The fix for that will be to create a Build API interface for BazelLibrary (e.g., "BazelLibraryAPI"). Refactored some GlobalFrame construction logic to be more uniform. Instead of constructing a whole Environment just to get a frame, we build the frame directly, using ImmutableMap.Builder to accumulate bindings. This convention may further change once we convert MethodLibrary and the like to @SkylarkGlobalLibrary, but for now it's more readable. RELNOTES: None PiperOrigin-RevId: 194960824
* Make runfiles usage on Windows more flexible to support remote execution.Gravatar Googler2018-04-30
| | | | | | | | | | | | | | | When trying to find a runfile on Windows: 1. First look for the runfiles MANIFEST and find runfile locations using this if it exists (current behavior). 2. If no MANIFEST file exists, look for runfiles in the runfiles directory (new behavior). As part of this, remove setting RUNFILES_MANIFEST_ONLY for the benefit of test-setup.sh. Instead of telling it what to do, it decides what to do based on the observed state of the world. Launchers still set RUNFILES_MANIFEST_ONLY for the benefit of launched programs, since some may depend on this. Fixes https://github.com/bazelbuild/bazel/issues/4962. RELNOTES: Remote execution works for Windows binaries with launchers. PiperOrigin-RevId: 194785440
* c++,runfiles: move runfiles libraryGravatar Laszlo Csomor2018-04-30
| | | | | | | | | | | | | | | | Move the half-done C++ runfiles library to `//tools/cpp/runfiles`. (The Python and Bash runfiles libraries are already under `//tools/<language>/runfiles`.) See https://github.com/bazelbuild/bazel/issues/4460 Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7 Closes #5107. Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7 PiperOrigin-RevId: 194763392
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* For --checkHashMismatch=ERROR, emit all errors instead of stopping at the ↵Gravatar cushon2018-04-26
| | | | | | first one PiperOrigin-RevId: 194491274
* java,runfiles: merge classesGravatar Laszlo Csomor2018-04-25
| | | | | | | | | | | | | | | | | | | | | | This commit prepares simplifying the Java runfiles library, which itself prepares mergint the manifest-based and directory-based logic so that the Runfiles class could handle both at the same time. This commit only moves classes around: - moves the ManifestBased and DirectoryBased classes into Runfiles, as nested classes - adds a createManifestBasedForTesting and createDirectoryBasedForTesting method to create the classes for testing - moves the ManifestBasedTest and DirectoryBasedTest into RunfilesTest Otherwise this commit has no functional change. Change-Id: I56b582c1a95793b0a871748697673b53a780f0fb PiperOrigin-RevId: 194227675
* Automated rollback of commit 047688a129b444ba918ae4c31767dce73b17b049.Gravatar Googler2018-04-24
| | | | | | | | | | | | | *** Reason for rollback *** This broke Hangouts Meet on Android tests: [] *** Original change description *** Add support for pseudo locales to ResourceLinker. RELNOTES: None PiperOrigin-RevId: 194167109
* Add support for pseudo locales to ResourceLinker.Gravatar corysmith2018-04-24
| | | | | RELNOTES: None PiperOrigin-RevId: 194126334
* runfiles: rlocation() checks if arg is normalizedGravatar Laszlo Csomor2018-04-24
| | | | | | | | | | | | | | | | | | | rlocation() now validates that the path argument is normalized, i.e. contains none of: - current directory references (".") - uplevel references ("..") - double slash ("//") This helps avoiding a bug similar to https://github.com/bazelbuild/bazel/pull/5083. See https://github.com/bazelbuild/bazel/pull/4460 Change-Id: Ia73fa2df1eae86fc7084162c24e144129672742d Closes #5085. Change-Id: Ia73fa2df1eae86fc7084162c24e144129672742d PiperOrigin-RevId: 194074072
* windows,client: fix error reportingGravatar Laszlo Csomor2018-04-24
| | | | | | | | | | | | | | | | | | | | | | Fix error reporting in the path conversion methods of the Bazel client. Previously the error reporting logic used GetLastErrorString in places where it was not appropriate (i.e. it was not a failed Windows API call that caused an error). This cleanup prepares removing the concept of the MSYS root from the Bazel client, since MSYS paths are no longer supported and we want to cut Bazel's dependency on Bash (thus MSYS) completely. See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088 Closes #5072. Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088 PiperOrigin-RevId: 194052665
* Add error message on empty public resourcesGravatar asteinb2018-04-23
| | | | | | | | This should provide more understandable behavior in the case described in https://github.com/bazelbuild/bazel/issues/5077 RELNOTES: none PiperOrigin-RevId: 193968203
* Don't add -u flag to local remote worker docker command on Windows.Gravatar Googler2018-04-20
| | | | | | | | | | | | | | | | | -u doesn't currently make sense for Windows: https://github.com/docker/for-win/issues/636#issuecomment-293653788 The local remote worker happens to sometimes work on Windows because we would frequently (always?) hit the timeout here (but recently this hasn't been the case for me): https://github.com/bazelbuild/bazel/blob/fa36d2f48965b127e8fd397348d16e991135bfb6/src/tools/remote/src/main/java/com/google/devtools/build/remote/worker/ExecutionServer.java#L323 When we don't hit the timeout (so "id -u" succeeds, and the "-u" flag is passed to docker), we get an error like this: ``` Error response from daemon: container 06851b64e09bab5a930bfb706892785b24c7538c1a7be826fef315ab8e62c117 encountered an error during CreateProcess: failure in a Windows system call: The user name or password is incorrect. (0x52e) ``` The method for detecting Windows is the best I could find, similar to other isWindows functions in Bazel. RELNOTES: None. PiperOrigin-RevId: 193666199
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-28 07:57:30 +0000