aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CcCommon.java
Commit message (Collapse)AuthorAge
* Extract logic for dealing with CROSSTOOL values and build variables into ↵Gravatar rosica2018-05-14
| | | | | | | separate class RELNOTES: None. PiperOrigin-RevId: 196517537
* 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
* Remove cppConfiguration from LinkBuildVariablesGravatar hlopko2018-05-08
| | | | | | | | | This is to simplify the API that will eventually be exposed to Skylark. Working towards #4571. RELNOTES: None. PiperOrigin-RevId: 195785588
* Make the static_link_cpp_runtimes feature settableGravatar Googler2018-04-24
| | | | | | | | | | | 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
* 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
* Thread more information through CcToolchainProvider for ↵Gravatar hlopko2018-04-20
| | | | | | | | | | 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
* Push using ruleContext.getFeatures() outside of creating FeatureConfigurationGravatar hlopko2018-04-17
| | | | | | | | 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
* Push using ruleContext.getDisabledFeatures() outside of creating ↵Gravatar hlopko2018-04-16
| | | | | | | | | | 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
* 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
* Remove c++-link-interface-dynamic-library from crosstools, it's not usedGravatar hlopko2018-04-05
| | | | | RELNOTES: None. PiperOrigin-RevId: 191713379
* Also add blaze-bin directory for "includes" attributeGravatar Googler2018-04-03
| | | | | | | | This fixes cc_library rules for third-party packages using generated headers in blaze-bin. RELNOTES: None. PiperOrigin-RevId: 191485462
* 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
* Isolate C++ compile build variablesGravatar hlopko2018-03-27
| | | | | | | | | | | | | | 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
* Automated rollback of commit 67549a752c2316234b19d7b50ea84a8ae80d3669.Gravatar hlopko2018-03-21
| | | | | | | | | | | | | | | | | | | | | | | | *** 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
* Automated rollback of commit 3c5a1098af0c5ae80d4e3b1fc52dd1fef6027d43.Gravatar hlopko2018-03-21
| | | | | | | | | | | | | | | | *** 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
* Add crosstool_lib.bzl and crosstool_utils.bzlGravatar hlopko2018-03-21
| | | | | | | | These will be used to rewrite current crosstool autoconfiguration into action_configs and features. RELNOTES: None. PiperOrigin-RevId: 189888171
* Allow optimization related features to be ignored when unsupported as ↵Gravatar Googler2018-03-15
| | | | | | opposed to reporting errors PiperOrigin-RevId: 189201637
* 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
* Deletes CODEC fields now that they are no longer needed.Gravatar shahan2018-02-28
| | | | PiperOrigin-RevId: 187397314
* Move enabling of coverage related features to CcCommonGravatar Googler2018-02-23
| | | | | | | | Move dealing with coverage related features from CppConfiguration.configurationEnabledFeatures to CcCommon.configureFeatures. Remove configurationEnabledFeatures. RELNOTES: None. PiperOrigin-RevId: 186744803
* 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
* Route fdo logic that deals with the path to the fdo profile through ↵Gravatar Googler2018-02-20
| | | | | | | | | | 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
* C++: Removes CppModel classGravatar plf2018-02-15
| | | | | | | The logic is split between CcCompilationHelper and CcLinkingHelper. RELNOTES:none PiperOrigin-RevId: 185809915
* Replace path implementation.Gravatar tomlu2018-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* 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
* Add a CODEC for some dependencies of CppCompileAction: CompileCommandLine andGravatar cpeyser2018-02-07
| | | | | | | | CcToolchainFeatures.Variables. We rephrase the nocopts filter from a Predicate<String> to a custom class, since AutoCodec cannot serialize a Predicate. PiperOrigin-RevId: 184902162
* C++: Stops generating DWO files when PER_OBJECT_DEBUG_INFO feature is not ↵Gravatar plf2018-02-02
| | | | | | | enabled. RELNOTES:none PiperOrigin-RevId: 184303490
* Fix usages of PathFragment segments that will become inefficient.Gravatar tomlu2018-01-19
| | | | | | | An upcoming replacement to PathFragment will not have efficient segment semantics, causing code to become unnecessarily inefficient. RELNOTES: None PiperOrigin-RevId: 182553098
* Only return a nocopts matcher if the attribute is explicitly specified.Gravatar tomlu2017-12-21
| | | | | | | Previously we'd return a matcher even for empty attributes. Pattern matching in Java generates garbage. RELNOTES: None PiperOrigin-RevId: 179864316
* Remove CppConfiguration#supportsFission and #useFission. To do this, we:Gravatar cpeyser2017-12-20
| | | | | | | | | | | | (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
* Remove FeatureSpecification, use plain sets insteadGravatar hlopko2017-12-19
| | | | | RELNOTES: None. PiperOrigin-RevId: 179534164
* Remove source category from CcCommon.configureFeaturesGravatar hlopko2017-12-19
| | | | | | | | Inline SourceCategory.CC action configs, as CC is the only source category that is ever passed to this method. RELNOTES: None. PiperOrigin-RevId: 179522955
* Migrate callsites of CppConfiguation#getCompiler, #getTargetLibc, #getCpu toGravatar cpeyser2017-11-28
| | | | | | | CcToolchainProvider. Toolchain information must be removed from CppConfiguration to allow the c++ rules to use hermetic platforms. PiperOrigin-RevId: 177163880
* 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
* Save dwoFile on LTOBackendArtifacts objectGravatar Googler2017-11-14
| | | | | | | | | 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
* Add win_def_file attribute to cc rules.Gravatar Yun Peng2017-11-14
| | | | | | | | 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
* Allow an action_config to be activated by default.Gravatar cpeyser2017-11-13
| | | | PiperOrigin-RevId: 175531318
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | 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
* Move CppConfiguration#toolchainNeedsPic, #getRuntimeSysroot, andGravatar cpeyser2017-10-31
| | | | | | #getSolibDirectory to CcToolchainProvider. PiperOrigin-RevId: 174032021
* Add platform_common.MakeVariableInfo so that Skylark code has access to the ↵Gravatar lberki2017-10-27
| | | | | | | Make variables provider. RELNOTES: None. PiperOrigin-RevId: 173527191
* Move expansion functionality to a new classGravatar ulfjack2017-09-29
| | | | | | Progress on #2475. PiperOrigin-RevId: 170473111
* 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
* Simplify make variable expansion call sitesGravatar ulfjack2017-09-28
| | | | | | Progress on #2475. PiperOrigin-RevId: 170197341
* Rewrite CppHelper linkopts expansion to take a list and return a listGravatar ulfjack2017-09-27
| | | | | | Progress on #2475. PiperOrigin-RevId: 170187908
* 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
* Do not duplicate build variables, reuse variables from cc toolchainGravatar hlopko2017-09-19
| | | | | | | | | | | 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