aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLinkingHelper.java
Commit message (Collapse)AuthorAge
* C++: Deletes CcLinkParamsInfoGravatar plf2018-05-15
| | | | | | | | This class is not necessary anymore. We can use CcLinkParamsStoreImpl directly which has been renamed to CcLinkParamsStore. RELNOTES:none PiperOrigin-RevId: 196656488
* Extract logic for dealing with CROSSTOOL values and build variables into ↵Gravatar rosica2018-05-14
| | | | | | | separate class RELNOTES: None. PiperOrigin-RevId: 196517537
* C++: Renames CcRunfilesInfo to CcRunfilesGravatar plf2018-05-14
| | | | | | | Since it's not a provider, it doesn't need the Info suffix anymore. RELNOTES:none PiperOrigin-RevId: 196505329
* C++: Renames CcCompilationContextInfo to CcCompilationContextGravatar plf2018-05-14
| | | | | | | Since it's not a provider, it doesn't need the Info suffix anymore. RELNOTES:none PiperOrigin-RevId: 196498526
* Rename LinkStaticness to LinkingMode and unify with the other LinkingMode.Gravatar hlopko2018-05-07
| | | | | RELNOTES: None. PiperOrigin-RevId: 195777400
* Rename Staticness to LinkerOrArchiver.Gravatar hlopko2018-05-07
| | | | | | | | | 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
* C++: Wraps CcExecutionDynamicLibrariesInfo inside CcLinkingInfo.Gravatar plf2018-04-20
| | | | | RELNOTES:none PiperOrigin-RevId: 193657227
* C++: Wraps CcRunfilesInfo inside CcLinkingInfo.Gravatar plf2018-04-20
| | | | | | | 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
* C++: Wrap CcLinkParamsInfo with CcLinkingInfo.Gravatar plf2018-04-16
| | | | | | | 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
* Make statically linking cpp-runtimes as a crosstool feature.Gravatar Googler2018-04-12
| | | | | | | | | 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
* Automated rollback of commit 77c5582fa0f5c829df576d9f8d66f4975fe415a6.Gravatar hlopko2018-04-06
| | | | PiperOrigin-RevId: 191880445
* Make statically linking cpp-runtimes as a crosstool feature.Gravatar Googler2018-04-05
| | | | | | | | | | | 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
* C++: Migrate CppRunfilesProvider to new provider styleGravatar plf2018-04-04
| | | | | RELNOTES:none PiperOrigin-RevId: 191576814
* C++: Migrate CcExecutionDynamicLibrary to new provider styleGravatar plf2018-04-04
| | | | | RELNOTES:none PiperOrigin-RevId: 191574019
* C++: Rename CcCompilationInfo to CcCompilationContextInfo.Gravatar plf2018-04-03
| | | | | | | | | 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
* C++: Remove headers from input to linking action.Gravatar plf2018-03-29
| | | | | | | | | 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
* C++: Fixes Blaze crashing on CLIF in toolchains that don't need PICGravatar plf2018-03-27
| | | | | | | | | | | | | | | | | | | | 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
* Ensure -fPIC set on shared non-LTO backends as neededGravatar Googler2018-03-22
| | | | | | | | | | | | | | 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
* C++: Marks Skylark exposed as not documented.Gravatar plf2018-03-08
| | | | | | | This is to avoid listing them in the Bazel docs for now. RELNOTES:none PiperOrigin-RevId: 188295824
* C++: Exposes to Skylark basic API functionalityGravatar plf2018-03-02
| | | | | RELNOTES:none PiperOrigin-RevId: 187591225
* Introduce a specific action_config for linking nodeps dynamic librariesGravatar hlopko2018-03-01
| | | | | | | | | | | | | 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
* C++: Renames CppCompilationContext to CcCompilationInfoGravatar plf2018-02-21
| | | | | | | This is in preparation for migrating to the new way of specifying providers as described in[] RELNOTES:none PiperOrigin-RevId: 186436462
* C++: Removes CppModel classGravatar plf2018-02-15
| | | | | | | The logic is split between CcCompilationHelper and CcLinkingHelper. RELNOTES:none PiperOrigin-RevId: 185809915
* C++: Split C++ library into two classes, compilation and linkingGravatar plf2018-02-08
These will be separate calls in the Skylark API. RELNOTES:none PiperOrigin-RevId: 184961734
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-01 21:46:05 +0000