| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
recommended if there are no object files", when versioned shared library is in srcs fields like "a.so.2.0".
In appearsToHaveObjectFiles(), we take into account SHARED_LIBRARY, but no VERSIONED_SHARED_LIBRARY.
Fixes #310 .
--
MOS_MIGRATED_REVID=138408789
|
|
|
|
|
|
|
| |
RELNOTES: Comparing sets (`if set1 < set2:`) is not allowed anymore in Skylark because it didn't work correctly anyway.
--
MOS_MIGRATED_REVID=138408411
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138391269
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138387292
|
|
|
|
|
|
|
|
| |
away -- Bazel should still work with remote execution servers that don't have
that optimization.
--
MOS_MIGRATED_REVID=138384785
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For SpawnActions, depending on the value of use_default_shell_env,
the specified environment is taken. The shell environment, however,
consists of two parts: a static mapping of variables to values, and
a set of variables where the value is to be taken from the client
environment. Make sure, both parts are set correctly. Fixes #2035.
--
Change-Id: I32253e9bf651b18ca25107edc5fc839813905726
Reviewed-on: https://bazel-review.googlesource.com/#/c/7211
MOS_MIGRATED_REVID=138376914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks tests on latest, as proto_lang_toolchain didn't make it into the 0.4.0 release
see http://ci.bazel.io/job/bazel-tests/306/BAZEL_VERSION=latest,PLATFORM_NAME=linux-x86_64/console
*** Original change description ***
Use proto_lang_toolchain() in java_proto_library.
--
MOS_MIGRATED_REVID=138372522
|
|
|
|
|
|
|
|
|
|
|
| |
context should generate a module map and module.
This whole code is a bit convoluted and the increasing number of boolean
parameters to initializeCppCompilationContext is smelly. I plan to clean this
up in a follow-up CL.
--
MOS_MIGRATED_REVID=138286169
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138231767
|
|
|
|
|
|
|
|
|
| |
documentation.
Fixes #1877.
--
MOS_MIGRATED_REVID=138199724
|
|
|
|
|
|
|
|
|
| |
This was an oversight on my part in the original implementation. As one
example, the Firebase AAR libraries contain AndroidManifest.xml's
with ${applicationId} and Google Play Services contain <meta-data> tags.
--
MOS_MIGRATED_REVID=138198047
|
|
|
|
|
|
|
| |
Add doc for the "read only" error message.
--
MOS_MIGRATED_REVID=138194709
|
|
|
|
|
|
|
| |
RELNOTES: Do not propagate aspect to its own attributes when using '*'.
--
MOS_MIGRATED_REVID=138194456
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change updates WindowsFileSystem so it:
- retrieves the DosFileAttributes instead of the
BasicFileAttributes, because the latter does not
report junctions as directories
- uses just isJunction to decide if a file is a
symlink, doesn't look at whether it's a
directory (again because java.nio.File also
incorrectly reports junctions as
non-directories)
Fixes https://github.com/bazelbuild/bazel/issues/1850
--
MOS_MIGRATED_REVID=138187220
|
|
|
|
|
|
|
| |
CompilationSupport.
--
MOS_MIGRATED_REVID=138185198
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138182982
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138180229
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138161512
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138143803
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138112581
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Firebase Android libraries contain lots of AARs with manifests that include
${applicationId}. As far as I can tell, tools/android/merge_manifests.py only
allows for substitution of ${packageName} and not arbitrary placeholder
substitution. The new aar_import rule exposes the AARs in <sdk>/extras which
include include the Firebase Android libraries.
RELNOTES: Default android_manifest_merger is now "android" which uses the official Android manifest merger. http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger
--
MOS_MIGRATED_REVID=138109902
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138104417
|
|
|
|
|
|
|
|
|
|
|
|
| |
blacklist.
This is intead of taking an attribute name and reading it inside of the class.
Motivation: using proto_lang_toolchain() rules means there's no longer an attribute that points at the blacklist.
Instead, we have an attribute that points at the toolchain, which itself points at the blacklist.
--
MOS_MIGRATED_REVID=138096096
|
|
|
|
|
|
|
| |
map, to emphasize that order matters.
--
MOS_MIGRATED_REVID=138090273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
delimited).
Adds --experimental_build_event_binary_file option that enables varint delimited proto loggging to the specified file path
Adds varint delimited BuildEventStreamTransport and BuildEventStreamerModule
Adds BuildEventStreamerModule for configuring and setting up BuildEventStreamer and its associated BuildEventTransports.
Adds BuildEventTransportFactory which creates a Set of transports from command options.
Moves BuildEventStreamer configuration from BlazeCommandDispatcher and BuildEventStreamerModule
--
Change-Id: If71f2b58654879c2509206da47e6d1a846bf397f
Reviewed-on: https://bazel-review.googlesource.com/#/c/7010/
MOS_MIGRATED_REVID=138073726
|
|
|
|
|
|
|
| |
GITHUB: #1752
--
MOS_MIGRATED_REVID=138072464
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138039276
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138005602
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138004628
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When rewriting stable-status.txt, which happens on each build, avoid updating
the file's ctime and mtime if the new contents match what is already in the
file.
This prevents tickling the TimestampGranularityMonitor for what should be a
no-op update, which in turn could cause null/incremental builds to stall for
up to a second. The problem was magnified on macOS where the default HFS+
file system only has second-level granularity. (This also affects Linux, but
because current Linux file systems have milli/nanosecond-level granularity,
the wait imposed by TimestampGranularityMonitor is minimal and thus not
generally noticeable.)
--
MOS_MIGRATED_REVID=137983794
|
|
|
|
|
|
|
|
|
|
|
| |
instantiation of HttpDownloader and RepositoryCache in BazelRepositoryModule.
There are sufficient similarities between the download flows of HttpDownloader and MavenDownloader such that we can extend HttpDownloader to MavenDownloader, and reuse method headers such as checkCache and download.
GITHUB: #1752
--
MOS_MIGRATED_REVID=137982375
|
|
|
|
|
|
|
| |
protos natively.
--
MOS_MIGRATED_REVID=137980688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create the runfiles directory for the shell stub
script (bazel-bin/foo/bar_bin and
bazel-bin/foo/bar_bin.runfiles) but use the batch
script as the runfiles provider's executable
(bazel-bin/foo/bar_bin.cmd). This way we the shell
stub script can still find its runfiles (under its
parent directory + its base name + ".runfiles)
while "bazel run" can also work on Windows.
Fixes https://github.com/bazelbuild/bazel/issues/2025
See https://github.com/bazelbuild/bazel/issues/1925
--
MOS_MIGRATED_REVID=137965442
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We wind up doing String -> UTF8 bytes conversion for every message serialized
(this happens in protocol buffer land). Do the conversion once and reuse the
immutable value instead of doing it for every chunk of output written.
Keep this optimization local to RpcOutputStream where we see a lot of
repitition - using ByteStrings in place of Strings can get confusing when it
comes to logging, so only apply this optimization where it could count.
--
MOS_MIGRATED_REVID=137964305
|
|
|
|
|
|
|
|
|
|
|
| |
For each test target, also have a test summary as children to this event.
As test summaries are posted on the event bus anyway, it is enough to
make then an instance of BuildEvent.
--
Change-Id: Id53e5f1760548a1fa621b1667fdb4470f51a52e8
Reviewed-on: https://bazel-review.googlesource.com/#/c/6931
MOS_MIGRATED_REVID=137961100
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke internal builds.
--
MOS_MIGRATED_REVID=137959459
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137955061
|
|
|
|
|
|
|
|
|
|
| |
Bypass converting bytes to string - RecordOutputStream is typically used to
wrap stdout/err, which we write bytes to, the string step is waste.
Make defensive copies of byte[]s passed to Event since Event doesn't.
--
MOS_MIGRATED_REVID=137949714
|
|
|
|
|
|
|
| |
This CL also contains a small refactoring that should make the introduction of list-int-mulitplication easier.
--
MOS_MIGRATED_REVID=137938998
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137936478
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137935119
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137886595
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137877037
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Firebase Android libraries contain lots of AARs with manifests that include
${applicationId}. As far as I can tell, tools/android/merge_manifests.py only
allows for substitution of ${packageName} and not arbitrary placeholder
substitution. The new aar_import rule exposes the AARs in <sdk>/extras which
include include the Firebase Android libraries.
RELNOTES: Default android_manifest_merger is now "android" which uses the official Android manifest merger. http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger
--
MOS_MIGRATED_REVID=137875695
|
|
|
|
|
|
|
|
| |
No need for the char[] in the middle, prevents us from accidentally modifying
input, or sucking up ram on huge queries.
--
MOS_MIGRATED_REVID=137872573
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137871914
|
|
|
|
|
|
|
|
|
|
| |
This is a workaround for a clang bug. See
https://code.google.com/p/android/issues/detail?id=220159.
RELNOTES: Fix for Android clang++ std::stack segfault on 32bit x86. See https://code.google.com/p/android/issues/detail?id=220159
--
MOS_MIGRATED_REVID=137871199
|
|
|
|
|
|
|
|
| |
These new log statements help in understanding what files trigger the
TimestampGranularityMonitor's wait logic and when the wait is performed.
--
MOS_MIGRATED_REVID=137868235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Constant metadata" artifacts represent real files whose changes should be
ignored by the build system. However, these artifacts were triggering the
timestamp granularity checks in TimestampGranularityMonitor because the fact
that they were "constant metadata" was not respected. Avoid this so that
their regeneration does not cause the build to unnecessarily stall.
One of these artifacts is the volatile workspace status file, which is
unconditionally updated on each build. Before this fix, "blaze build" would
get stuck for up to a second waiting for file system timestamps to catch up.
With this fix, the artifact is ignored and the wait is gone. This problem
is magnified on macOS where the default HFS+ file system only has
second-level granularity. (This also affects Linux, but because current
Linux file systems have milli/nanosecond-level granularity, the wait imposed
by TimestampGranularityMonitor is minimal and thus not generally noticeable.)
--
MOS_MIGRATED_REVID=137867586
|
|
|
|
|
|
|
| |
predictable iteration order.
--
MOS_MIGRATED_REVID=137864799
|