| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
separate class
RELNOTES: None.
PiperOrigin-RevId: 196517537
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196498526
|
|
|
|
|
|
|
|
|
| |
This is to simplify the API that will eventually be exposed to Skylark.
Working towards #4571.
RELNOTES: None.
PiperOrigin-RevId: 195785588
|
|
|
|
|
|
|
|
|
|
|
| |
as a normal feature.
Prior to this cl, it was always set by examining
supports_embedded_runtimes.
DELTA_BY_EXTENSION=java=100,py=15
RELNOTES: None
PiperOrigin-RevId: 194172053
|
|
|
|
|
|
|
|
|
| |
This method will be available to Skylark. Native rules will use the wrapped
version in CcCommon.configureFeaturesOrReportRuleError. The error message shown
in case of conflicting features was modified slightly.
RELNOTES: None.
PiperOrigin-RevId: 193639182
|
|
|
|
|
|
|
|
|
|
| |
CcCommon.configureFeatures
The goal is to enable creation of feature configuration without the rule
context. This will enable us to have cleaner API for this in Skylark.
RELNOTES: None
PiperOrigin-RevId: 193630386
|
|
|
|
|
|
|
|
| |
The goal is to enable creation of feature configuration without the rule
context. This will enable us to have cleaner API for this in Skylark.
RELNOTES: None
PiperOrigin-RevId: 193195986
|
|
|
|
|
|
|
|
|
|
| |
FeatureConfiguration
The goal is to enable creation of feature configuration without the rule
context. This will enable us to have cleaner API for this in Skylark.
RELNOTES: None
PiperOrigin-RevId: 193017868
|
|
|
|
|
|
|
|
|
| |
This cl should result in no user-visible change. It simply
sets the feature based on the field in the crosstool proto.
A subsequent cl will expose this feature for people to actually
use.
PiperOrigin-RevId: 192641438
|
|
|
|
| |
PiperOrigin-RevId: 191880445
|
|
|
|
|
|
|
|
|
|
|
| |
This cl should result in no user-visible change. It simply
sets the feature based on the field in the crosstool proto.
A subsequent cl will expose this feature for people to actually
use.
DELTA_BY_EXTENSION=java=100,py=15
RELNOTES: None
PiperOrigin-RevId: 191761838
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 191713379
|
|
|
|
|
|
|
|
| |
This fixes cc_library rules for third-party packages using generated headers in
blaze-bin.
RELNOTES: None.
PiperOrigin-RevId: 191485462
|
|
|
|
|
|
|
|
|
| |
This is done so that the name CcCompilationInfo can be used for the C++
provider that will wrap all providers for compilation, similar to JavaInfo in
Java.
RELNOTES:none
PiperOrigin-RevId: 191445120
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For CLIF it doesn't matter whether we use PIC or no-PIC, the important thing
is we get an output protobuf. Before https://github.com/bazelbuild/bazel/commit/35773928532c132e3229b490ad98f4ebfd3e5770, using no-PIC was hardcoded.
In this CL it was decided to generate PIC instead because the toolchains used
by CLIF targets appeared to all have needsPic. In b/73955395 it has been shown
not to be the case.
In this CL I'm changing the logic again to use no-PIC for CLIF and to
circumvent the logic that checks what the configuration and the toolchain say.
At the same time, SWIG also used the method setGenerateNoPic() after the
variable onlySingleOutput was removed in https://github.com/bazelbuild/bazel/commit/4e9c9f93b15dd2594097644c6b9ca5a579c712fb. In this CL I use the
enum to apply PIC and no-PIC in the same cases as before for SWIG.
This CL also refactors the methods and boolean variables used to determine whether to use PIC or not, hopefully making it clearer.
RELNOTES:none
PiperOrigin-RevId: 190615548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a preparation work to expose Variables instance for all compile actions
to Skylark.
I didn't do linking variables in this cl, because this cl is already too big.
But they're coming shortly in a separate cl.
This is also in line with our goal to make build variables more discoverable and
better document.
RELNOTES: None.
PiperOrigin-RevId: 190591080
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks on windows: https://www.google.com/url?sa=D&q=https%3A%2F%2Fbuildkite.com%2Fbazel%2Fgoogle-bazel-presubmit%2Fbuilds%2F624%234a68440b-948b-437b-a633-4f0595721bab
*** Original change description ***
Automated rollback of commit 3c5a1098af0c5ae80d4e3b1fc52dd1fef6027d43.
*** Reason for rollback ***
Breaks bazel ci: https://github.com/bazelbuild/bazel/issues/4894#event-1533040075
*** Original change description ***
Add crosstool_lib.bzl and crosstool_utils.bzl
These will be used to rewrite current crosstool autoconfiguration into
action_configs and features.
RELNOTES: None.
PiperOrigin-RevId: 189906675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks bazel ci: https://github.com/bazelbuild/bazel/issues/4894#event-1533040075
*** Original change description ***
Add crosstool_lib.bzl and crosstool_utils.bzl
These will be used to rewrite current crosstool autoconfiguration into
action_configs and features.
RELNOTES: None.
PiperOrigin-RevId: 189901308
|
|
|
|
|
|
|
|
| |
These will be used to rewrite current crosstool autoconfiguration into
action_configs and features.
RELNOTES: None.
PiperOrigin-RevId: 189888171
|
|
|
|
|
|
| |
opposed to reporting errors
PiperOrigin-RevId: 189201637
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this cl toolchain author can specify different flags for linking shared
library produced by cc_library and a shared library produced by cc_binary.
This is what is needed to remove linking_mode_flags - MOSTLY_STATIC_LIBRARIES
from the crosstool. What this linking mode was used for was to separate when we
link transitive shared library from cc_binary and when we link this
little-and-not-really-useful-outside-of-bazel nodeps shared library in cc_library.
RELNOTES: CcToolchain: Introduced action_config for "c++-link-transitive-dynamic-library"
PiperOrigin-RevId: 187523334
|
|
|
|
| |
PiperOrigin-RevId: 187397314
|
|
|
|
|
|
|
|
| |
Move dealing with coverage related features from CppConfiguration.configurationEnabledFeatures to CcCommon.configureFeatures.
Remove configurationEnabledFeatures.
RELNOTES: None.
PiperOrigin-RevId: 186744803
|
|
|
|
|
|
|
| |
This is in preparation for migrating to the new way of specifying providers as described in[]
RELNOTES:none
PiperOrigin-RevId: 186436462
|
|
|
|
|
|
|
|
|
|
| |
CcToolchainProvider
As --fdo_optimize can point to a label, the path to the fdo profile can not be reliably determined in CppConfiguration.
In order to enable the fdo features (which depend on the path to the fdo profile), the logic from CppConfiguration.configurationEnabledFeatures() has been moved to CcCommon.configureFeatures(). The latter method has access to the fdo profile path through CcToolchainProvider.
RELNOTES: None.
PiperOrigin-RevId: 186278311
|
|
|
|
|
|
|
| |
The logic is split between CcCompilationHelper and CcLinkingHelper.
RELNOTES:none
PiperOrigin-RevId: 185809915
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Path and PathFragment have been replaced with String-based implementations. They are pretty similar, but each method is dissimilar enough that I did not feel sharing code was appropriate.
A summary of changes:
PATH
====
* Subsumes LocalPath (deleted, its tests repurposed)
* Use a simple string to back Path
* Path instances are no longer interned; Reference equality will no longer work
* Always normalized (same as before)
* Some operations will now be slower, like instance compares (which were previously just a reference check)
* Multiple identical paths will now consume more memory since they are not interned
PATH FRAGMENT
=============
* Use a simple string to back PathFragment
* No more segment arrays with interned strings
* Always normalized
* Remove isNormalized
* Replace some isNormalizied uses with containsUpLevelReferences() to check if path fragments try to escape their scope
* To check if user input is normalized, supply static methods on PathFragment to validate the string before constructing a PathFragment
* Because PathFragments are always normalized, we have to replace checks for literal "." from PathFragment#getPathString to PathFragment#getSafePathString. The latter returns "." for the empty string.
* The previous implementation supported efficient segment semantics (segment count, iterating over segments). This is now expensive since we do longer have a segment array.
ARTIFACT
========
* Remove Path instance. It is instead dynamically constructed on request. This is necessary to avoid this CL becoming a memory regression.
RELNOTES: None
PiperOrigin-RevId: 185062932
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Encore of https://github.com/bazelbuild/bazel/commit/f26e8694ae78599b3e2004e3360eaf3443fa53a6.
RELNOTES: None.
PiperOrigin-RevId: 184981106
|
|
|
|
|
|
|
| |
These will be separate calls in the Skylark API.
RELNOTES:none
PiperOrigin-RevId: 184961734
|
|
|
|
|
|
|
|
| |
CcToolchainFeatures.Variables.
We rephrase the nocopts filter from a Predicate<String> to a custom class, since AutoCodec cannot serialize a Predicate.
PiperOrigin-RevId: 184902162
|
|
|
|
|
|
|
| |
enabled.
RELNOTES:none
PiperOrigin-RevId: 184303490
|
|
|
|
|
|
|
| |
An upcoming replacement to PathFragment will not have efficient segment semantics, causing code to become unnecessarily inefficient.
RELNOTES: None
PiperOrigin-RevId: 182553098
|
|
|
|
|
|
|
| |
Previously we'd return a matcher even for empty attributes. Pattern matching in Java generates garbage.
RELNOTES: None
PiperOrigin-RevId: 179864316
|
|
|
|
|
|
|
|
|
|
|
|
| |
(1) Remove configuration-level warnings arising from fission.
(2) Move the setting of the "per_object_debug_info" feature from the
configuration to FeatureConfiguration construction in the analysis phase.
(3) Access the c++ toolchain in java_binary to decide on stripping.
In order to migrate the c++ rules to platform-based toolchain resolution, we
must remove all toolchain information from CppConfiguration.
PiperOrigin-RevId: 179682420
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179534164
|
|
|
|
|
|
|
|
| |
Inline SourceCategory.CC action configs, as CC is the only source category that
is ever passed to this method.
RELNOTES: None.
PiperOrigin-RevId: 179522955
|
|
|
|
|
|
|
| |
CcToolchainProvider. Toolchain information must be removed from
CppConfiguration to allow the c++ rules to use hermetic platforms.
PiperOrigin-RevId: 177163880
|
|
|
|
|
|
|
|
|
| |
and #getDynamicMode to CcToolchainProvider and CppHelper.
Moving toolchain info out of CppConfiguration is required to use platform-based
toolchain resolution in the c++ rules.
PiperOrigin-RevId: 176662686
|
|
|
|
|
|
|
|
|
| |
This is some clean up pulled out of unknown commit. It avoids needing
to reconstruct the dwoFile, which will be harder when we move to
using shared LTO backends in some cases.
RELNOTES: None
PiperOrigin-RevId: 175692708
|
|
|
|
|
|
|
|
| |
RELNOTES[NEW]: Users can use win_def_file attribute to specify a DEF file for
exporting symbols when build a shared library on Windows.
Change-Id: Ifa28d8b7b24eaefcefc9640d8dc56fd2931e9688
PiperOrigin-RevId: 175651203
|
|
|
|
| |
PiperOrigin-RevId: 175531318
|
|
|
|
|
|
|
|
| |
Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own.
This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually.
PiperOrigin-RevId: 175033526
|
|
|
|
|
|
| |
#getSolibDirectory to CcToolchainProvider.
PiperOrigin-RevId: 174032021
|
|
|
|
|
|
|
| |
Make variables provider.
RELNOTES: None.
PiperOrigin-RevId: 173527191
|
|
|
|
|
|
| |
Progress on #2475.
PiperOrigin-RevId: 170473111
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't ideal - RuleContext should not have state, but this ended up
happening between adding a cache and refactoring how make variables are
discovered.
I have carefully traced back all callers that provide custom make variable
suppliers and added an init call to their rule initialization. Note that the
ConfigurationMakeVariableContext is _cached_, so callers that call in without
any make variable suppliers and then call again with them would get the context
from the previous call.
We now enforce that the ConfigurationMakeVariableContext is only initialized
once, and that this happens before any usage, which is slightly better than the
previous state, where initialization was silently ignored on any subsequent
call.
Progress on #2475.
PiperOrigin-RevId: 170312285
|
|
|
|
|
|
| |
Progress on #2475.
PiperOrigin-RevId: 170197341
|
|
|
|
|
|
| |
Progress on #2475.
PiperOrigin-RevId: 170187908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to replace using USE_DYNAMIC_CRT env variable to configure
msvcrt linking in CROSSTOOL.
If user applies static_link_msvcrt feature to a specific target,
Bazel will choose the correct options for statically linking msvcrt.
If static_link_msvcrt is not specified, Bazel uses options for dynamically linking
msvcrt by default.
https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Change-Id: Ia078dfb528de9ffdd8a11d392db9eb3f34463b09
PiperOrigin-RevId: 170021927
|
|
|
|
|
|
|
|
|
|
|
| |
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
|