| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196793557
|
|
|
|
|
|
|
|
| |
This class is not necessary anymore. We can use CcLinkParamsStoreImpl directly
which has been renamed to CcLinkParamsStore.
RELNOTES:none
PiperOrigin-RevId: 196656488
|
|
|
|
|
|
|
| |
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: 196505329
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196498526
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195777400
|
|
|
|
|
|
|
|
|
| |
Staticness is confusing, I always have to investigate which is Staticness and
which is LinkStaticness, and even in isolation staticness is not a great name. I
believe LinkerOrArchiver is a better name :)
RELNOTES: None.
PiperOrigin-RevId: 195674810
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 193657227
|
|
|
|
|
|
|
| |
This simplifies the exposure to Skylark. It also helps by not forcing us to expose to Skylark providers that may eventually be deleted.
RELNOTES:none
PiperOrigin-RevId: 193645766
|
|
|
|
|
|
|
| |
CcLinkingInfo will eventually wrap all C++ linking providers. CcLinkParamsInfo is no longer a provider and will be renamed in a later CL.
RELNOTES:none
PiperOrigin-RevId: 193011702
|
|
|
|
|
|
|
|
|
| |
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: 191576814
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 191574019
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Headers were made an input to the linking action simply to get an error when we have a src-less cc_library with declared but missing headers. Since there was no compilation action, the headers were not an input to any action and there was no error when the files were missing.
After discussing it with the team, it was decided that this is not needed anymore. Files can be missing as long as they are not consumed.
RELNOTES:none
PiperOrigin-RevId: 190915591
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set the usePicForLtoBackend bit on the link action builder when we create
static link actions. Before https://github.com/bazelbuild/bazel/commit/8c5e290dfab3cab378a9ca107ecdd6267403cd4b this wasn't required for static
library link actions, as the LTO backend actions weren't created until the
dependent binary's link action, which set this flag for the binary static link.
However, with that change, we now create shared non-LTO backend actions early,
when creating the library link action, for use later when we create the binary
link action. So that flag needs to be set properly on the static library link
action to get the -fPIC flag set as needed on the shared non-LTO backends.
RELNOTES: None
PiperOrigin-RevId: 190074918
|
|
|
|
|
|
|
| |
This is to avoid listing them in the Bazel docs for now.
RELNOTES:none
PiperOrigin-RevId: 188295824
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 187591225
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This is in preparation for migrating to the new way of specifying providers as described in[]
RELNOTES:none
PiperOrigin-RevId: 186436462
|
|
|
|
|
|
|
| |
The logic is split between CcCompilationHelper and CcLinkingHelper.
RELNOTES:none
PiperOrigin-RevId: 185809915
|
|
These will be separate calls in the Skylark API.
RELNOTES:none
PiperOrigin-RevId: 184961734
|