| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
WorkerTestStrategy as well, to better log errors.
RELNOTES: None
PiperOrigin-RevId: 154080821
|
|
|
|
| |
PiperOrigin-RevId: 154078281
|
|
|
|
|
|
| |
to CompilationSupport to clean up that expanding API.
PiperOrigin-RevId: 154077775
|
|
|
|
|
|
|
|
|
| |
Avoiding duplicating code between the branches for handling
the Java and c++ implementations, and skip the
--resources flag if there are no resources. Both of these
changes should be no-ops.
PiperOrigin-RevId: 154055528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are now four concrete implementations: RelativeUnixPathFragment, AbsoluteUnixPathFragment, RelativeWindowsPathFragment, AbsoluteWindowsPathFragment.
Goals:
-Reduce memory usage of PathFragment on non-Windows platforms while maintaining existing semantics.
-Make a few simple performance improvements along the way.
-Add TODOs for a few more simple performance improvements.
-Open the way for reducing code complexity of PathFragment. All of the Windows-specific stuff ought not complicate the code so much.
Non goals:
-Make the entire codebase as pretty as possible wrt PathFragment & Windows.
-Make PathFragment usage more sane in general (e.g. change semantics to ban coexistence of Windows and Unix PathFragments).
-Optimize PathFragment as much as possible wrt memory or even in any other dimensions (e.g. gc churn, cpu).
To elaborate, the primary motivation is per-instance memory usage of PathFragment on Unix platforms:
Before this change
------------------
+UseCompressedOops --> 32 bytes per instance
-UseCompressedOops --> 40 bytes per instance
After this change
------------------
+UseCompressedOops --> 24 bytes per instance
-UseCompressedOops --> 32 bytes per instance
Since Bazel can retain lots of PathFragments, the memory savings of this CL are fairly large.
RELNOTES: None
PiperOrigin-RevId: 154052905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BEP (build event protocol) upload may at times take longer than the build
itself. This is especially true for cached builds, where there is little build
work, but the protocol still needs to be uploaded. In this case the bazel UI
will now display that it's waiting for BEP upload, both in the current and the
new experimental UI (--experimental_ui).
When executing a run command, blaze waits for the BEP upload to finish before
it runs the target.
Major Modifications:
- The BuildEventTransport interface now also has a name() method that returns
a string. When waiting for a transport to finish the BEP upload, this string
is displayed in the UI.
- The BuildEventStreamer now emits two new events
AnnounceBuildEventTransportsEvent and BuildEventTransportClosed on the event
bus. This is how the experimental UI is informed about BEP upload progress.
RELNOTES: None
PiperOrigin-RevId: 154052401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel always miscounted the number of passes that a test was run,
resulting in confusing output like this:
philwo@philwo:~/src/errortest$ bazel test //tests:fail
[...]
//tests:fail FAILED in 1 out of 2 in 0.1s
ERROR .tests/fail
It shows "1 out of 2" even though just one pass happened.
With this fix, the output is correct:
philwo@philwo:~/src/errortest$ bazel test //tests:fail
[...]
//tests:fail FAILED in 0.1s
ERROR .tests/fail
Relevant to #2855.
PiperOrigin-RevId: 154043240
|
|
|
|
|
|
|
|
|
| |
the host.
Also add a single instance of that platform for standard usage.
Change-Id: I0e7a8eb3a44099076540c8d955fc0c0c70447583
PiperOrigin-RevId: 153878880
|
|
|
|
|
| |
Change-Id: Ib2bbd1b35985c4ec2d1e411aea4b32af7433a426
PiperOrigin-RevId: 153856560
|
|
|
|
| |
PiperOrigin-RevId: 153831526
|
|
|
|
|
|
|
|
|
|
| |
For the TargetComplete event (not for the completion of aspects) readd
the reporting of outputs, but only for the default output group. This
will help existing applications to still report the outputs of a target,
till they transferred to handling named sets of files.
Change-Id: I1b0730b38bdc18f8fb2ccf859a7fee8f1b7f0cac
PiperOrigin-RevId: 153828334
|
|
|
|
|
|
|
|
|
|
|
| |
selected even if they're not the preferred one on a platform.
Simplify the SandboxActionContextProvider and remove the warning about
sandboxing being unsupported. With the ProcessWrapperSandboxedStrategy
now being reliable enough and the strategies printing their real name in
the UI, this is overall a better UX.
PiperOrigin-RevId: 153825986
|
|
|
|
|
|
| |
With the process-wrapper improvements and the additional deletion of the sandbox base in the SandboxModule in, this should be reliable enough. The warning was also not actionable for users and annoyed them, so let's get rid of it.
PiperOrigin-RevId: 153823045
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 153807467
|
|
|
|
|
|
|
|
|
| |
The consumers of ":lipo_context_collector" only do anything with it in
optimization builds.
Also remove an outdated comment in FdoSupport.
PiperOrigin-RevId: 153748937
|
|
|
|
|
|
|
|
|
|
|
| |
Because SkylarkClassObject declares equals, hashCode, and toString,
AutoValue doesn't bother creating those, but since these classes didn't
pass any data back to SkylarkClassObject, the defined methods don't work
properly. This shows up as all instances of a class having the same
hashCode and being equals() to each other.
Change-Id: I50734f04369231cd2141dd368b04a3f0997a7d18
PiperOrigin-RevId: 153735995
|
|
|
|
|
|
| |
Fixes #2853.
PiperOrigin-RevId: 153730500
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 153716003
|
|
|
|
|
|
| |
This feature is unused and depends on emma, which is obsolete.
PiperOrigin-RevId: 153713051
|
|
|
|
|
|
|
|
|
| |
the bug that the RemoteWorker would fail to upload outputs that were too big to send in a single gRPC message.
Fixes #2822.
RELNOTES: n/a
PiperOrigin-RevId: 153710733
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, we correctly replaced CppConfiguration with HipCppConfiguration for hip
builds, but we didn't update FeatureConfiguration. As Blaze was not using
action_configs for compile actions, compiler tool was taken from configuration
at the action creation time, not from FeatureConfiguration, so the tool was
correct. Command line flags (some of them) were computed by
FeatureConfiguration, but luckily the toolchains were so similar that it
worked.
In https://github.com/bazelbuild/bazel/commit/e1d692e486a2f838c3c894fd9de693fabd6685ed I tried to use action_configs for compile actions. The result
was that compiler tool was taken from configuration at the CppConfiguration
creation time, that was put into FeatureConfiguration, and that was used in
action creation time. Sadly, the tool in CppConfiguration was different that
the tool in HipCppConfiguration, and b/37315875 was discovered.
This cl also uppdates FeatureConfiguration when HipCppConfiguration is
replaced.
RELNOTES: None.
PiperOrigin-RevId: 153710405
|
|
|
|
|
|
|
|
|
|
| |
This module rely on an un-maintained codepath and is hardly used by anyone.
We should also archive the code from dash until we can revive it with BEP
RELNOTES[INC]: --use_dash, --dash_url and --dash_secret are removed.
PiperOrigin-RevId: 153701824
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to lookup repositories as part of converting exec paths to artifacts,
which in turn is needed for action cache lookups. These lookups should not
cause a Skyframe exit, so we must not throw an exception here, unless the
error makes it impossible to continue. Instead, we need to leave the decision
whether to error out or not to the caller.
Note that we may unnecessarily fetch a remote repository in order to do the
action cache lookup, even if the action no longer depends on the input file,
although this should only be possible for C++ compile actions. It's possible
that there's another bug in the C++ compile action key computation that also
contributes.
This change also makes it so that the post-resolution action cache code
ignores any errors wrt. repository lookup rather than throwing. If any of the
paths could not be found, then the action cache lookup fails and we re-execute
the corresponding action, which is exactly what should happen.
Fixes #2759.
PiperOrigin-RevId: 153696243
|
|
|
|
|
|
|
| |
list of built-in include directories available to Skylark through it.
RELNOTES: None.
PiperOrigin-RevId: 153684976
|
|
|
|
|
|
| |
Fixes #1413.
PiperOrigin-RevId: 153684106
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
The depot has been fixed: unknown commit
*** Original change description ***
Partial rollback of unknown commit
PiperOrigin-RevId: 153646328
|
|
|
|
|
|
|
|
| |
Add a dynamic equivalent for LIPO_COLLECTOR transition.
Rename LipoDataTransition (which handles DATA transition) to DisableLipoTransition. A future change will add a corresponding EnableLipoTransition (which will model TARGET_CONFIG_FOR_LIPO).
PiperOrigin-RevId: 153611898
|
|
|
|
|
|
| |
TESTED: local server
RELNOTES: n/a
PiperOrigin-RevId: 153599636
|
|
|
|
|
|
|
|
|
|
|
| |
RELNOTES: Adds a --override_repository option that takes a repository
name and path. This forces Bazel to use the directory at that path
for the repository. Example usage:
`--override_repository=foo=/home/user/gitroot/foo`.
Fixes #1266
PiperOrigin-RevId: 153599291
|
|
|
|
|
| |
WANT_LGTM=all
PiperOrigin-RevId: 153584480
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to minimize the likelihood of obscure policy conflict. Now, the last policy on
a flag (after policy expansion) will be the only one in the "canonical" invocation
policy. There should be no reason for explicitly setting multiple policies on a single
flag, but if an expansion flag is policy'd and one of its children has a more specific
policy on it, make sure that the policy on the child flag is after the policy on the
expansion flag.
Note that this restriction (only the last policy gets applied) also applies for repeatable flags. Make sure all values being set to a repeatable flag are set in a single SetValue operation, with multiple flagValues set.
PiperOrigin-RevId: 153584034
|
|
|
|
|
|
|
|
| |
This is the Blaze side of the support for emitting and using minimized bitcode files during the LTO indexing (thin link) step of a ThinLTO build. The llvm support has already been released to stable, and this needs to be submitted after the companion Crosstool support (unknown commit, will send for review once this larger part is reviewed).
This enables large applications successfully build using ThinLTO and -g, otherwise the bitcode files that are input to the LTO indexing step are huge and the maximum input size is exceeded.
PiperOrigin-RevId: 153549687
|
|
|
|
| |
PiperOrigin-RevId: 153545346
|
|
|
|
| |
PiperOrigin-RevId: 153531483
|
|
|
|
|
|
|
|
| |
If minimum_os is unspecified on an apple_binary target and ios_multi_cpus is not set, no
apple_binary configuration transition is made.
RELNOTES: None.
PiperOrigin-RevId: 153529598
|
|
|
|
|
|
|
| |
of xctest apps are seen by ios_test
RELNOTES: None.
PiperOrigin-RevId: 153529262
|
|
|
|
|
|
|
|
| |
restrictions.
Prevent the old category strings "undocumented," "hidden," or "internal" from being used as categories, to prevent developers from relying on deprecated behavior.
PiperOrigin-RevId: 153525499
|
|
|
|
|
|
|
|
|
|
| |
The key change is to eliminate the need to transition from the data to the target configuration by relying on out-of-band configuration state. Specifically, the old model drops LIPO options from the data configuration. In the cases when we have to switch back (i.e. TARGET_CONFIG_FOR_LIPO), those options have to get re-injected somehow. Static configurations achieve this with the global configuration transitions table. But dynamic configs have no comparable source (and they consciously eschew global state).
This cl changes the model to *keep* LIPO settings in the data config, then use a new "enableOrDisable" flag to determine whether or not to actually use them. With this model, the data -> target transition is now as simple as toggling that flag.
This change doesn't actually add dynamic config LIPO support. It's doing enough as it is, and we need to make sure it doesn't break existing LIPO semantics. Dynamic support will come as a followup.
PiperOrigin-RevId: 153504240
|
|
|
|
|
|
| |
#2147
PiperOrigin-RevId: 153494286
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/2743.
RELNOTES: android_library exports_manifest now defaults to True.
PiperOrigin-RevId: 153493900
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 153489730
|
|
|
|
|
|
|
|
|
|
| |
This is already fixed in the CachedLocalSpawnRunner, with tests there, which
will replace RemoteSpawnStrategy in the near future. For now, I'd like to get
this in in time for 0.5.0 to get test caching working.
Fixes #1413.
PiperOrigin-RevId: 153486592
|
|
|
|
| |
PiperOrigin-RevId: 153485708
|
|
|
|
| |
PiperOrigin-RevId: 153473961
|
|
|
|
|
|
| |
All genjar actions have very short command lines.
PiperOrigin-RevId: 153468708
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1cd2096284959ead26687d1d58b695d2abffb8e2.
That commit tried to find a more suitable python binary by
following symlinks. That, however, is not necessary, as
our follow-up infrastructure can call symbolic links and
our tests os.path.isfile(path) and os.access(path, os.X_OK)
follow symbolic links as well.
Fixes #2836.
Change-Id: If37589622d141265577eb3872f68342ae1c263dc
PiperOrigin-RevId: 153461118
|
|
|
|
|
|
|
|
|
|
| |
Only write a cache entry when the spawn executed successfully, and with a 0
exit code. In the test, we only check that uploadFileContents is called exactly
twice.
Progress on #1413.
PiperOrigin-RevId: 153458240
|
|
|
|
|
|
|
|
| |
This is a prerequisite for Google to use it; there's no consistent logging
strategy yet, but Google internally requires logging, and it needs to be
somewhat backwards compatible.
PiperOrigin-RevId: 153454160
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 153449924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Add /Z7 as compiler flag in CROSSTOOL, this causes full debugging
infomation built into object files, no PDB file is generated.
2. Add /DEBUG as linker flag so that a PDB file will be generated for
executable or dll.
* /DEBUG:FULL for dbg mode. the full PDB can be used to debug the
executable when no other build products are available, such as
when the executable is deployed.
* /DEBUG:FASTLINK for fastbuild mode. object files are still needed
when debugging the executable, but linking speed can be two to four
times faster that full PDB generation.
* No option is added for opt mode.
More detailed info: https://msdn.microsoft.com/en-us/library/xe4t6fc1.aspx
3. Add an empty feature in MSVC CROSSTOOL to tell Bazel we need PDB file
4. Add PDB file artifact in an output named pdb_file of cc_binary,
then you can build the pdb file by bazel build //foo/bar:bin --output_groups=pdb_file
5. Add test for PDB file generation
Change-Id: Ia5096470187ebca72f2c804f32d5b723f40c0b85
PiperOrigin-RevId: 153449059
|