aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibrary.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
* 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
* Add an extra argument to CcCompilationHelper#fromCommon() that contains ↵Gravatar lberki2018-04-26
| | | | | | | additional compiler options. RELNOTES: None. PiperOrigin-RevId: 194363080
* Automated rollback of commit 404483d99bca4edc0600e72cacfcc36404fd4653.Gravatar hlopko2018-04-25
| | | | | | RELNOTES: None. PiperOrigin-RevId: 194353580
* Add an extra argument to CcCompilationHelper#fromCommon() that contains ↵Gravatar lberki2018-04-25
| | | | | | | additional compiler options. RELNOTES: None. PiperOrigin-RevId: 194232650
* 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
* Extract CcCommon.configureFeaturesOrThrowEvalExceptionGravatar hlopko2018-04-20
| | | | | | | | | 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
* 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++: 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++: 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
* Expose an actions provider on RuleConfiguredTarget instances.Gravatar cparsons2018-03-06
| | | | | | | | | Given a target (for example from a skylark aspect), one will be able to access a list of actions that the target generated using "target.actions". This is without additional memory footprint. Actions themselves are not fully exposed to skylark (and thus there isn't much meaning to gather from them in skylark yet). Access methods will follow soon. RELNOTES: None. PiperOrigin-RevId: 188098079
* 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
* C++: Only call link() in cc_binary when linkCompileOutputSeparately is true.Gravatar plf2018-01-12
| | | | | | | | | Also rename setLinkType() to setStaticLinkType() in CcLibraryHelper to make it clear that we are setting the specific linking type for the static library. This is an improved version of https://github.com/bazelbuild/bazel/commit/a705eaa9225ff8a03975c8cb49faa6b2899e398d which was rolled back due to a previous conflicting CL causing problems in the nightly. RELNOTES:none PiperOrigin-RevId: 181746447
* Automated rollback of commit c166cd99ce9f72eed522e78d63c93ff410b6dc18.Gravatar plf2018-01-11
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** This was missing adding LTO files in the cc_embed_data rule. Fixed and added test. *** Original change description *** Automated rollback of commit 67330ad52391ad6562d439f77cc5133a0ea4247d. *** Reason for rollback *** Breaks nightly: b/71790513 *** Original change description *** C++ refactoring: Separate compilation and linking calls to CcLibraryHelper RELNOTES:none PiperOrigin-RevId: 181613477
* Automated rollback of commit 67330ad52391ad6562d439f77cc5133a0ea4247d.Gravatar plf2018-01-10
| | | | | | | | | | | | | *** Reason for rollback *** Breaks nightly: b/71790513 *** Original change description *** C++ refactoring: Separate compilation and linking calls to CcLibraryHelper RELNOTES:none PiperOrigin-RevId: 181457811
* C++ refactoring: Separate compilation and linking calls to CcLibraryHelperGravatar plf2018-01-08
| | | | | RELNOTES:none PiperOrigin-RevId: 181169134
* Rename OutputGroupProvider -> OutputGroupInfo.Gravatar dslomov2017-12-14
| | | | | RELNOTES: None PiperOrigin-RevId: 179046403
* Implement cc_import ruleGravatar Yun Peng2017-12-07
| | | | | | | | | | Designed here: https://docs.google.com/document/d/1hK2mWl3TYNL9oJYX_S020TKkXZvBw1aBoYERvTHVyfg/edit Fix https://github.com/bazelbuild/bazel/issues/3402 Change-Id: I9beff94d8b85ffeb4e46e0959c8f5ed4ef9c6268 PiperOrigin-RevId: 178238408
* Add C++ Make variables to cc_binary, cc_library, and cc_test automatically whenGravatar cpeyser2017-11-29
| | | | | | | | | Make variables are derived from toolchain. This will allow c++ targets to use c++ Make variables once platforms are activated without declaring an explicit dependency on the c++ toolchain. PiperOrigin-RevId: 177365568
* Move CppConfiguration's treatment of pic, --start-lib/--end-lib, and fission toGravatar cpeyser2017-11-22
| | | | | | | | | | | CppHelper. In CppHelper, CcToolchainProvider and CppConfiguration are used sepereately, allowing toolchain information to be removed from CppConfiguration. This is necessary to introduce hermetic toolchains, which require that toolchain information be seperated from the configuration, into the c++ rules. PiperOrigin-RevId: 176694160
* Migrate CppConfiguration#supportsGoldLinker, supportsDynamicLinker,Gravatar cpeyser2017-10-31
| | | | | | supportsEmbeddedRuntimes, supportsExecOrigin to CcToolchainProvider. PiperOrigin-RevId: 173928009
* Make the state in RuleContext explicitGravatar ulfjack2017-09-28
| | | | | | | | | | | | | | | | | | | | | 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
* Remove unnecessary collectLinkstamp switchGravatar hlopko2017-09-25
| | | | | | | All callers passed true, so there's no need to have the boolean there. RELNOTES: None. PiperOrigin-RevId: 169888322
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Bazel now can build dynamic library from cc_libraryGravatar Yun Peng2017-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Working towards: https://github.com/bazelbuild/bazel/issues/3311 When building dynamic library on Windows, Bazel builds an import library and a DLL. Bazel provides a feature called windows_export_all_symbols, if this feature is enabled(and no_windows_export_all_symbols is not) for a cc_library, then Bazel parses object files of that cc_library to generate a DEF file that will be used during linking time to export symbols from DLL. This feature can be specified at crosstool, package, target and command line level. A few differences from Unix platforms: 1. We don't build the shared library on Windows by default, users have to specifiy --output_groups=dynamic_library for building dynamic libraries. This output group is also available on other platforms. 2. By default, cc_test is dynamically linked on Unix, but it will be statically linked on Windows by default. (meaning the default value of linkstatic in cc_test is 1 on Windows, and 0 on other platforms) 3. For global data symbols, __declspec(dllimport) must still be used in source files. Remaining issues: 1. Extensions for import library and DLL are not correct yet. 2. DLLs are not guaranteed to be available during runtime yet. 3. Diamond problem If a cc_library A is specified as linkstatic=0, then no dynamic library will be built for it, so if another cc_library B depends on it, A will be statically linked into B, and if a cc_binary C depends on B, A will also be statically linked into C and B will be dynamically linked to C. This is wrong because A is duplicated in both B and C. It is essentially a diamond problem describled in C++ Transitive Library. (https://docs.google.com/document/d/1-tv0_79zGyBoDmaP_pYWaBVUwHUteLpAs90_rUl-VY8/edit?usp=sharing) Hopefully, we can avoid this by using cc_shared_library rule in future. Change-Id: I23640d4caf8afe65d60b1522af6368536d7a8408 PiperOrigin-RevId: 168829958
* Move core test classes to lib.analysis.testGravatar ulfjack2017-08-11
| | | | | | | | These are depended upon by analysis code, so need to live in the same library as lib.analysis. Moving them here makes it possible to split the build-base library into separate libraries for analysis, execution, and rules. PiperOrigin-RevId: 164847161
* Rename some variables for easier understanding of the code.Gravatar elenairina2017-08-09
| | | | PiperOrigin-RevId: 164581142
* Move RuleConfiguredTargetFactory to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164446955
* Make native declared providers type-safe.Gravatar dslomov2017-07-10
| | | | | RELNOTES: None. PiperOrigin-RevId: 161395570
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* Implement OutputGroupInfo provider.Gravatar dslomov2017-05-03
| | | | | | | Work towards #2894. RELNOTES: None. PiperOrigin-RevId: 154829065
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | 'create' method. This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment). This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations. RELNOTES: None PiperOrigin-RevId: 152145768
* apple_binary scopes link artifacts using child configuration for ↵Gravatar Cal Peyser2017-03-14
| | | | | | | | --experimental_objc_crosstool=all -- PiperOrigin-RevId: 150066766 MOS_MIGRATED_REVID=150066766
* Early support for code generation directly from C++ module files. This canGravatar Googler2017-02-15
| | | | | | | | | | | | potentially reduce the linker input. The content of a C++ module (specifically the inline definitions) is currently put into every single .o file that uses them and thus can be input to the same final link many times. By generating a separate .o file for the module itself, we can avoid this unnecessary duplication of linker input. -- PiperOrigin-RevId: 147579947 MOS_MIGRATED_REVID=147579947
* Remove type checking requirement from AttributeMap.has.Gravatar Greg Estren2017-02-15
| | | | | | | | | | | | | | This overrides the traditional has(String name, Type<>T> type) with has(String name) and removes the type check outright from isConfigurable. Ideally we'd remove the old version in this same change. But there are enough uses of it that that's not a risk-free change and is safer as followup changes. -- PiperOrigin-RevId: 147513593 MOS_MIGRATED_REVID=147513593
* Stop retrieving FdoSupport statically from hard-coded attribute ↵Gravatar Rumou Duan2017-02-14
| | | | | | | | | | ":cc_toolchain" in RuleContext, instead take the provider from users and pass it around to where it is used. This gives J2ObjcAspect the ability to specify the C++ toolchain attribute under a different name to avoid attribute conflicts with attached rules that have already declared attribute ":cc_toolchain". -- PiperOrigin-RevId: 147358325 MOS_MIGRATED_REVID=147358325
* Stop retrieving CcToolChainProvider statically from hard-coded attribute ↵Gravatar Rumou Duan2017-02-08
| | | | | | | | | | ":cc_toolchain" in RuleContext, instead take the provider from users and pass it around to where it is used. This gives J2ObjcAspect the ability to specify the C++ toolchain attribute under a different name to avoid attribute conflicts with attached rules that have already declared attribute ":cc_toolchain". -- PiperOrigin-RevId: 146920294 MOS_MIGRATED_REVID=146920294
* Add option to dynamically link in the compilation output of cc_test andGravatar Googler2016-12-16
| | | | | | | | | | | | | | | | | | | cc_binary if we are doing dynamic linking anyway. The additional option is only for a smooth rollout and will go away once everything works as expected. The benefit is in an incremental save-build-test-cycle. When editing a test (or any of it's transitive headers), the linker input currently changes, meaning we need to do the full link again before the test can run. However, in conjunction with the option --interface_shared_objects, this actually isn't necessary. With this new option, the test source gets compiled into a .so file and while that file changes with each source change, the .ifso file often does not change. Thus, the costly link linking to gether all the .so and .ifso files can be retrieved from cache. Thus, this change should remove this linking step from the critical path of many save-build-test-cycles. -- PiperOrigin-RevId: 142244352 MOS_MIGRATED_REVID=142244352
* Delete dead codeGravatar Marcel Hlopko2016-12-15
| | | | | | -- PiperOrigin-RevId: 142129925 MOS_MIGRATED_REVID=142129925
* Fix a bug that causes unnecessary warning "setting 'linkstatic=1' is ↵Gravatar Yuannan Cai2016-11-08
| | | | | | | | | | | 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
* Fix a bug that leads to unnecessary compiles of .pic.o files (and possibly)Gravatar Googler2016-09-12
| | | | | | | | | | | | | | | | | | | | | | others in opt compiles. A while back, we added a HIDDEN_TOP_LEVEL output group to CcBinary targets to ensure that --process_headers_in_dependencies works as expected for them. However, adding all HIDDEN_TOP_LEVEL files is actually too much and e.g. also contains .pic.o files which are expensive to build but not actually needed for the compile. The fundamental difference between CcLibrary and CcBinary targets here is that a CcBinary already declares most of its inputs as it needs all of them to link the binary. In contrast, CcLibraries wouldn't need any of they dependent .o files and thus wouldn't even try to build them. This changes splits out the header token files which are required to make --process_headers_in_dependencies work correctly and only adds those to HIDDEN_TOP_LEVEL outputs of binaries files. Also removing some unused code that was producing warnings. -- MOS_MIGRATED_REVID=132883722
* Remove the "cc_*.includes attribute must refer to the third_party directory" ↵Gravatar Lukacs Berki2016-08-31
| | | | | | | | | | | warning from Bazel. This behavior doesn't really make sense except within Google. Fixes #1286. -- MOS_MIGRATED_REVID=131813322
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-02 01:29:13 +0000