aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CppRuleClasses.java
Commit message (Collapse)AuthorAge
* Enable static_linking_mode or dynamic_linking_mode features from cc_binaryGravatar hlopko2018-03-09
| | | | | RELNOTES: CppRules: cc_binary/cc_test now enable 'static_linking_mode' or 'dynamic_linking_mode'. PiperOrigin-RevId: 188482267
* Add a binary to CppCompileAction that is responsible for grepping header ↵Gravatar ajmichael2018-03-07
| | | | | | | files for include statments. This binary is currently only used for an internal feature - but that feature may be supported externally eventually. RELNOTES: None PiperOrigin-RevId: 188173513
* Introduce -c source_file -o output_file build variablesGravatar hlopko2018-02-08
| | | | | | | | | | | | | | 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
* Stop allowing generic LateBoundDefault value types. Such types are always ↵Gravatar janakr2018-02-02
| | | | | | | | either a Label or a List<Label>. We can easily enforce this through static type checking, so do it. This will help with LateBoundDefault serialization, since we don't have to serialize an arbitrary object. PiperOrigin-RevId: 184347100
* Remove DynamicTransitionMapper, ConfigurationTransitionProxy.Gravatar gregce2018-01-30
| | | | PiperOrigin-RevId: 183826311
* Move PatchTransition and kin to analysis.config.transitions.Gravatar gregce2018-01-04
| | | | | | | HostTransition can't be migrated yet because it depends on BuildConfiguration. PiperOrigin-RevId: 180842784
* Replace Attribute.ConfigurationTransition with ↵Gravatar gregce2017-12-28
| | | | | | | | | | | | | | | | config.transitions.ConfigurationTransitionProxy. The "proxy" part is to dissuade people from writing: void myfunc(ConfigurationTransition transition) signatures casually. Maybe that's actually a better name than "Transition". But I'd rather rename Transition to ConfigurationTransition in its own change if we want to do that. PiperOrigin-RevId: 180285321
* Replace Attribute.Transition with config.transitions.Transition.Gravatar gregce2017-12-22
| | | | PiperOrigin-RevId: 179936355
* Support for ThinLTO to be enabled implicitly with AFDOGravatar Googler2017-12-20
| | | | | | | Allows for ThinLTO to be enabled once the --features=autofdo_implicit_thinlto feature is enabled in the crosstool. Also allows for --features=-thin_lto to override and prevent ThinLTO from being enabled. RELNOTES: None. PiperOrigin-RevId: 179687743
* Suppress ThinLTO indexing for linkstatic testsGravatar Googler2017-11-30
| | | | | | | | | | | | | ThinLTO and static linking of test suites is a bad combination since it results in a combinatorial explosion of the ThinLTO backends - each object file needs a separate LTO backend action per target. If you are static linking O(N) objects, and have O(M) targets, with ThinLTO you will get O(N*M) LTO backend jobs. This is because the whole program optimization step is per-target, and may make different decisions affecting the object files. With dynamic linking it isn't a problem, since the ThinLTO optimization happens at the .so level, which are shared across tests. And for statically-linked cc_binary it hasn't been an issue since typically only a single target is built at a time, unlike tests. In general it isn't incredibly useful to run tests with ThinLTO, although most projects are in the habit of running their tests with the same options that they use to optimize their main binary (and most blueprints seem to be set up to share options between them). With ThinLTO since it is doing whole-program optimization, you are getting different whole-program optimizations for the main binary and each test binary, so it isn't the case that this will optimize the tests in the same exact way as the main binary anyway. Therefore, when creating LTO backends for statically-linked *_test targets, skip the LTO indexing stage, and create (or use if already created) shared dummy LTO backend actions for each library. These LTO backends are fed an empty index, so they don't do any whole program optimization and are safe to share. Enable this under a new feature so that we can enable it by default via blazerc but provide a facility to disable if needed. RELNOTES: None PiperOrigin-RevId: 177495858
* Move CppConfiguration#isLLVMcompiler, #isLLVMOptimizedFdo, #isLipoOptimization,Gravatar cpeyser2017-11-22
| | | | | | | | | 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
* Windows: Add static_link_msvcrt and related featuresGravatar Yun Peng2017-09-26
| | | | | | | | | | | | | | | 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
* Use FeatureConfiguration to compute linkstamping compile command lineGravatar hlopko2017-09-25
| | | | | | | | | Before, linkstamping compile actions were hardcoded in bazel and assumed gcc/clang and bash. This cl removes gcc/clang assumptions by using feature configuration. RELNOTES: None. PiperOrigin-RevId: 169685949
* Windows: Make dynamic libraries available to binary at runtimeGravatar Yun Peng2017-09-20
| | | | | | | | | | | When copy_dynamic_libraries_to_binary is enabled, we copy the shared libraries required by the binary to the binary's directory. Bazel will throw errors if there are confilct actions generating the same artifacts. Change-Id: I09a5a599ca0ec7a67efd49d5aa89481450fa4e90 PiperOrigin-RevId: 169364498
* LateBoundDefault: enforce access to a single fragment (or none).Gravatar mstaib2017-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, there is no way to enforce that LateBoundDefaults only access the fragments that they declare. This means that LateBoundDefaults can fail to declare fragments at all, or declare the wrong ones, and still have no troubles. But when trimming, these fragments must be declared, because otherwise they will not necessarily be available. This change refactors LateBoundDefault to declare a single fragment type, not a set. All existing LateBoundDefaults use sets with a single element or no elements at all for their set of fragment classes, so this does not limit anything being done currently. To account for LateBoundDefaults which do not use configuration at all, typically those which only want to access the configured attribute map, it is possible for Void to be the fragment class which is requested. To account for LateBoundDefaults which need to access methods of the BuildConfiguration instance itself, it is possible for BuildConfiguration to be the fragment class which is requested; however, this is unsafe, so it is only a temporary state until a way to do this without also giving access to all of the fragments can be added. Drive-by refactoring: LateBoundDefaults' values are now typed. All actual production LateBoundDefaults were Label or List<Label> typed, through the LateBoundLabel and LateBoundLabelList subclasses. These subclasses have been removed, and LateBoundDefault has two type parameters, one for the type of its input, and one for the type of its output. RELNOTES: None. PiperOrigin-RevId: 169242278
* Remove LipoTransition (and replace remaining LIPO_COLLECTOR references).Gravatar gregce2017-09-18
| | | | | | | | Rules should now be configured directly with patch transitions. This brings down our transition interfaces to: Transition, ConfigurationTransition, SplitTransition, PatchTransition. PiperOrigin-RevId: 168927364
* Every rule class that uses a cc_toolchain also has knowledge of the label forGravatar cpeyser2017-09-18
| | | | | | the c++ toolchain type through an implicit attribute. PiperOrigin-RevId: 168864540
* Automated rollback of commit f26e8694ae78599b3e2004e3360eaf3443fa53a6.Gravatar hlopko2017-09-18
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks clang_tidy. *** Original change description *** Introduce -c source_file -o output_file build variables 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. RELNOTES: None. PiperOrigin-RevId: 168834576
* 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
* Introduce -c source_file -o output_file build variablesGravatar hlopko2017-09-14
| | | | | | | | | | | | 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. RELNOTES: None. PiperOrigin-RevId: 168671507
* Lots more cleanup of "dynamic configurations" comments and test code.Gravatar gregce2017-09-14
| | | | PiperOrigin-RevId: 168607439
* Remove outdated defaultsToSelf.Gravatar gregce2017-09-12
| | | | | | Part of the static config cleanup effort. PiperOrigin-RevId: 168270713
* Introduce unfiltered_compile_flags build variable, rename copts variable to ↵Gravatar hlopko2017-09-11
| | | | | | | | | | | | | user_compile_flags Also add magic to a feature named 'unfiltered_compile_flags' so the flags expanded from it are not subject to nocopt filtering. This is encore of https://github.com/bazelbuild/bazel/commit/268c0bcbf79f9f3f72d95fa51af0f1b18c5ce29e that was rolled back because it regressed memory. RELNOTES: None. PiperOrigin-RevId: 167989075
* Internal changeGravatar kush2017-09-07
| | | | PiperOrigin-RevId: 167751263
* Introduce unfiltered_compile_flags build variable, rename copts variable to ↵Gravatar hlopko2017-09-06
| | | | | | | | | | user_compile_flags Also add magic to a feature named 'unfiltered_compile_flags' so the flags expanded from it are not subject to nocopt filtering. RELNOTES: None. PiperOrigin-RevId: 167587189
* Automated rollback of commit fc41c430e4de4594a1d699f573d191cbad52a2fb.Gravatar plf2017-09-01
| | | | PiperOrigin-RevId: 167154793
* Move ObjcProvider FLAG into a new provider type (TransitiveSourcesProvider) ↵Gravatar cpeyser2017-08-30
| | | | | | that is accessible to the c++ rules. PiperOrigin-RevId: 166934390
* Replace TransitionApplier interface with a dedicated class.Gravatar gregce2017-08-21
| | | | | | | | | | | | | | | This accomplishes a few goals: 1. Removes the outdated BuildConfiguration.StaticConfigurationApplier code. 2. Removes the TransitionApplier abstraction completely. This was an awkward bridge meant to support both static and dynamic implementations. 3. Moves transition logic to its own dedicated class: ConfigurationResolver. This no longer belongs in BuildConfiguration, which we ultimately want to become a simple <key, value> map. Part of the static config cleanup effort. PiperOrigin-RevId: 165736955
* 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
* Do not add copts feature to crosstools that already define itGravatar hlopko2017-08-09
| | | | | RELNOTES: None. PiperOrigin-RevId: 164701570
* Add no_stripping feature to MSVC CROSSTOOLGravatar Yun Peng2017-08-04
| | | | | | | | | | | | If no_stripping feature is enabled, then strip action config is not necessary, building stripped binary will just copy the orignial binary. Fix https://github.com/bazelbuild/bazel/issues/3482 Also fixed CI breakage: https://github.com/bazelbuild/bazel/issues/3505 Change-Id: Ie78fe174c42248c9b3e930008eef96dcd1864741 PiperOrigin-RevId: 164237588
* Update the default values for the C++ and Java late-bound attributes to the ↵Gravatar janakr2017-07-10
| | | | | | correct //tools/cpp:toolchain and //tools/jdk:jdk. PiperOrigin-RevId: 161227981
* Factor out BuildConfigurationCollection.Transitions.getDynamicTransition.Gravatar gregce2017-07-07
| | | | | | | | | | | | This is a legacy dependency on the configuration transition table, which is only needed for static configurations. Dynamic configurations didn't actually use anything in that table: this was just a convenience interface that could have equally been defined somewhere else. So this cl defines it somewhere else. There's still one last dependency: Transitions.configurationHook. We'll tackle that in a followup cl. PiperOrigin-RevId: 161141650
* Make osx crosstool standalone (working without bazel patches)Gravatar hlopko2017-07-03
| | | | | | | | | | | | This cl promotes //tools/osx/crosstool to be fully specified on its own, without any blaze patches needed. While at it, I (think I) unified objc and c++ coverage features. Other than coverage, this cl only adds features that bazel would add otherwise. Ping #2420 RELNOTES: ObjC and C++ coverage feature is unified under name 'coverage' PiperOrigin-RevId: 160633192
* Automated g4 rollforward of commit b71e99b1f3746103e5d6802eebc24096b3494959.Gravatar gregce2017-06-05
| | | | | | | | | | | | | | | | | | | | | | | | (Automated g4 rollback of commit de92f9d8ea093416fae999073bbfcf3cf501ab55). *** Reason for rollback *** The problems that forced commit de92f9d8ea093416fae999073bbfcf3cf501ab55 were fixed in commit e6392cd380fce14d719890c78d5eb2657e8a6cfc . *** Original change description being rolled forward *** Implement dynamically configured LIPO builds. Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely.... *** ROLLBACK_OF=156180015 PiperOrigin-RevId: 157865224
* Automated g4 rollback of commit b71e99b1f3746103e5d6802eebc24096b3494959.Gravatar mstaib2017-05-17
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Causes crash bug in certain circumstances. *** Original change description *** Implement dynamically configured LIPO builds. Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely. This doesn't actually turn dynamic LIPO on. So the direct effect of this change should be a no-op. The flip will come in a followup change. For now, dynamic... PiperOrigin-RevId: 156180015
* Implement dynamically configured LIPO builds.Gravatar gregce2017-05-04
| | | | | | | | | | | | | | | Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely. This doesn't actually turn dynamic LIPO on. So the direct effect of this change should be a no-op. The flip will come in a followup change. For now, dynamic LIPO can be triggered with --experimental_dynamic_configs=notrim. PiperOrigin-RevId: 155096056
* Parse /showIncludes output for MSVC compilerGravatar Yun Peng2017-04-25
| | | | | | | | Instead of parsing .d file generated by wrapper script, we directly parse the output of /showIncludes option. Change-Id: Id94e20a5cb05a494a793fd6a43756d44d27cea8a PiperOrigin-RevId: 154161939
* Don't create the LIPO context collector subgraph for instrumentation builds.Gravatar gregce2017-04-24
| | | | | | | | | The consumers of ":lipo_context_collector" only do anything with it in optimization builds. Also remove an outdated comment in FdoSupport. PiperOrigin-RevId: 153748937
* Generating PDB files on WindowsGravatar Yun Peng2017-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Automated g4 rollback of commit e7c730ba64d1c34ac7049f4165a33dc1329d0019.Gravatar jfield2017-04-18
| | | | | | | | | | | | | | | *** Reason for rollback *** breaks tests *** Original change description *** Extract --sysroot flag from bazel and move it into crosstool This is an encore of https://github.com/bazelbuild/bazel/commit/6127358c1799d8d83cebbd499edac89f869df41b . RELNOTES: None. PiperOrigin-RevId: 153351147
* Extract --sysroot flag from bazel and move it into crosstoolGravatar hlopko2017-04-12
| | | | | | | This is an encore of https://github.com/bazelbuild/bazel/commit/6127358c1799d8d83cebbd499edac89f869df41b . RELNOTES: None. PiperOrigin-RevId: 152803621
* Automated g4 rollback of commit 05300b5945286f6063afbf1d16c9c8e5621c4828.Gravatar jmmv2017-03-31
| | | | | | | | | | | | | | *** Reason for rollback *** Breaks inclusion of C++ system headers. *** Original change description *** Extract --sysroot flag from blaze and move it into crosstool RELNOTES: None. PiperOrigin-RevId: 151742077
* Extract --sysroot flag from blaze and move it into crosstoolGravatar hlopko2017-03-31
| | | | | | RELNOTES: None. PiperOrigin-RevId: 151688820
* Genrules only depend on the C++ toolchain if they have C++ make variables. Gravatar Greg Estren2017-03-28
| | | | | | | | | | e.g.: cmd = "$(CC) foo.cc > $@" Fixes #2729 -- PiperOrigin-RevId: 151369889 MOS_MIGRATED_REVID=151369889
* Make the interface dynamic library builder a regular label instead of a ↵Gravatar Lukacs Berki2017-02-17
| | | | | | | | magic artifact. -- PiperOrigin-RevId: 147830857 MOS_MIGRATED_REVID=147830857
* 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
* experimental_objc_library excludes non-.h headers, as does objc_library.Gravatar Cal Peyser2017-02-09
| | | | | | -- PiperOrigin-RevId: 146958087 MOS_MIGRATED_REVID=146958087
* Add a flag that alters the behavior of the parse_headers feature. With theGravatar Googler2017-01-27
| | | | | | | | | | | | | flag, the headers of a target are compiled into a C++ module instead of being parsed as their own translation unit. The module otherwise remains unused. This way, parse_headers can be used to get a codebase ready for C++ modules. parse_headers currently already gets close, but there are still ways in which a header can be modules-incompatible although it parses fine. -- PiperOrigin-RevId: 145729231 MOS_MIGRATED_REVID=145729231
* experimental_objc_library excludes private headers from module maps. ThisGravatar Cal Peyser2017-01-24
| | | | | | | | brings it in line with the behavior in objc_library. -- PiperOrigin-RevId: 145330154 MOS_MIGRATED_REVID=145330154
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 12:03:47 +0000