aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp
Commit message (Collapse)AuthorAge
* Add fields to CcToolchainFeatures.Feature and ↵Gravatar rosica2018-06-19
| | | | | | | | | | | CcToolchainFeatures.ActionConfig that are needed for FeatureConfiguration creation In the future CcToolchainFeatures will not be created from a CToolchain but from a CrosstoolInfo provider that will encapsule all relevant information from the CROSSTOOL. Feature and ActionConfig classes need to carry all the information that is currently obtained from CToolchain. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 201147336
* Remove support for --discard_actions_after_execution.Gravatar tomlu2018-06-18
| | | | | | | The memory savings from this flag are not worth the complexity, and it interferes with action restarting. RELNOTES: Remove support for --discard_actions_after_execution. PiperOrigin-RevId: 201077905
* Allow CppCompilationHelper to disable coverage instrumentationGravatar Googler2018-06-15
| | | | | RELNOTES=None PiperOrigin-RevId: 200800112
* Remove LIPO supportGravatar hlopko2018-06-15
| | | | | RELNOTES: Support for LIPO has been fully removed. PiperOrigin-RevId: 200724578
* Remove CcCompilationContext.TransitiveModuleHeaders#getTransitiveModules. ↵Gravatar cpeyser2018-06-15
| | | | | | This information is persisted for testing only, and considerably slows NestedSet serialization. PiperOrigin-RevId: 200710549
* SerializationCheckingGraph checks all ConfiguredTargetValues.Gravatar cpeyser2018-06-14
| | | | PiperOrigin-RevId: 200593618
* Expose new methods in CcToolchainProvider to eventually replace skylark ↵Gravatar juliexxia2018-06-14
| | | | | | callables that depend on CToolchain in CppConfiguration. PiperOrigin-RevId: 200559893
* C++: Fixes error reporting for cc_importGravatar plf2018-06-14
| | | | | RELNOTES:none PiperOrigin-RevId: 200525022
* Avoid long, duplicated directory structures. In the common case, generatedGravatar Googler2018-06-13
| | | | | | | | files are going to be beneath the target that generates them. In this case, don't duplicated the package's path. RELNOTES: None. PiperOrigin-RevId: 200400464
* Remove supports_lipo field from DefaultCpuToolchainGravatar rosica2018-06-13
| | | | | RELNOTES: None. PiperOrigin-RevId: 200399094
* Add "toolchain-identifier" attribute to cc_toolchain ruleGravatar rosica2018-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the selection of C++ toolchain configuration depends on 2 different things: 1. CROSSTOOL file: a proto text file that contains multiple CrosstoolConfig.CToolchain messages, out of which we want to select the appropriate CToolchain; 2. cc_toolchain_suite rule, specified by --crosstool_top option: this rule contains "toolchains" map attribute. The map's keys are of type <cpu>|<compiler>, or just <cpu>, and the values are labels of cc_toolchain rules (which contain additional C++ information). If there is an entry in cc_toolchain_suite.toolchains that corresponds to the --cpu and --compiler options, we use it, otherwise we loop through all the CToolchains in the CROSSTOOL file, select the one that corresponds to the --cpu and --compiler options, and then get the cc_toolchain label from cc_toolchain_suite.toolchains[toolchain.targetCpu|toolchain.compiler]. In both cases we read the CROSSTOOL file and pass all its information forward, to be used in creation of CppConfiguration and CcToolchainProvider creation. As part of the efforts of rewriting CROSSTOOL in Skylark, we need to make obtaining the cc_toolchain label independent of the CROSSTOOL file and toolchain selection. As a step towards that goal, we add a new "toolchain_identifier" attribute to cc_toolchain, which uniquely identifies a CToolchain in the CROSSTOOL file. Now the process of getting the CToolchain goes as follows: Check for existence of cc_toolchain_suite.toolchains[<cpu>|<compiler>], if --compiler is specified, otherwise check for cc_toolchain_suite.toolchains[<cpu>]. 1. if a value is found, load the cc_toolchain rule and look for the toolchain_identifier attribute. 1.a if the attribute exists, loop through all the CToolchains in CROSSTOOL and select the one with the matching toolchain identifier. 1.b otherwise fall back to selecting the CToolchain from CROSSTOOL by matching the --cpu and --compiler values. 2. If a value is not found, select the CToolchain from CROSSTOOL by matching the --cpu and --compiler values, and construct the key as follows: <toolchain.cpu>|<toolchain.compiler>. In the future we will get rid of 2. by making sure that cc_toolchain_suite.toolchains[<cpu>|<compiler>] and cc_toolchain_suite.toolchains[<cpu>] are always defined. 1.b will be removed by making the cc_toolchain.toolchain_identifier attribute mandatory After this deriving the cc_toolchain label will be independent of the CROSSTOOL file 1.a will ultimately be replaced by an attribute that points to a skylark_crosstool rule, that will contain all the information that CROSSTOOL contains, allowing us to remove CROSSTOOL altogether. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 200388550
* Return Strings from C++ Skylark APIs, not PathFragmentsGravatar hlopko2018-06-13
| | | | | | | | | | PathFragments are not well supported in Skylark, quite the opposite, the Skylark team tries hard to not use path fragments if possible. All existing users I looked into had to convert the PathFragment to string using str() anyway. Because of that this cl should not break anybody. RELNOTES: None. PiperOrigin-RevId: 200372447
* C++: Continues renaming executionDynamicLibraries to dynamicLibrariesForRuntime.Gravatar plf2018-06-13
| | | | | RELNOTES:none PiperOrigin-RevId: 200366616
* Change generated DEF file name from <target name>.def to <target name>.gen.defGravatar pcloudy2018-06-13
| | | | | | | | | This helps avoid name conflicts when users want to generate DEF files by themselves. For example, when using a genrule to do that, people naturally name the def file as <target name>.def. Fixed https://github.com/bazelbuild/bazel/issues/5357 RELNOTES: None PiperOrigin-RevId: 200354303
* Add skylarkbuildapi bootstraps for apple, cpp, platform, and testing packagesGravatar cparsons2018-06-12
| | | | | RELNOTES: None. PiperOrigin-RevId: 200246780
* Migrate remaining assorted skylark types to skylarkbuildapiGravatar cparsons2018-06-11
| | | | | RELNOTES: None. PiperOrigin-RevId: 200100871
* Add AutoProfiler-like API to ProfilerGravatar ulfjack2018-06-11
| | | | | | - migrate all startTask/completeTask pairs to the new API PiperOrigin-RevId: 200038703
* Flip default value of --experimental_shortened_obj_file_path to true (Second ↵Gravatar pcloudy2018-06-08
| | | | | | | | | | try) This is a roll forward of https://github.com/bazelbuild/bazel/commit/3ab52e63079f1e43cb2c973425f615836a334082. The issue caused the objc rule breakage was fixed by https://github.com/bazelbuild/bazel/commit/5176300577b53a15128b3cb6a17d7883c5b7090e. RELNOTES: Flip default value of --experimental_shortened_obj_file_path to true, Bazel now generates short object file path by default. PiperOrigin-RevId: 199806300
* Expose cc_common.create_link_build_variablesGravatar hlopko2018-06-08
| | | | | | | | | | | This cl enabled skylark rules to create build variables used for C++ link actions (in a limited form, e.g. build variables for thinlto are not exposed etc). Working towards #4571. RELNOTES: None PiperOrigin-RevId: 199792130
* C++: Introduces flag to disable automatic expansion of labels in linkopts.Gravatar plf2018-06-07
| | | | | | | LSC is finished. RELNOTES:none PiperOrigin-RevId: 199619978
* Expose C++ action names to SkylarkGravatar hlopko2018-06-07
| | | | | | | | | | | | | | This cl adds Skylark constants allowing users to specify which C++ action they want for the feature configuration Skylark API. This is done by exposing a Skylark file at @bazel_tools//tools/cpp:action_names.bzl. Skylark api to the C++ toolchain doc: https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit#. Progress on #4571. RELNOTES: None. PiperOrigin-RevId: 199596778
* Refactoring: makes the code simpler by deleting Metadata and InputArtifactData.Gravatar shahan2018-06-06
| | | | | | (minor) ActionFS now implements MetadataProvider.getInput PiperOrigin-RevId: 199575194
* Build support for enabling cross binary FDO optimization.Gravatar Googler2018-06-06
| | | | | | | Crossbinary FDO optimization is a special form of AutoFDO which uses a synthetic profile to optimize targets without any profile. The synthetic profile will often be used as a default profile and will use .xfdo as suffix. It will be passed though option -fdo_optimize just like Autofdo profile. If .xfdo file is passed through -fdo_optimize in the same command line with other types of profiles, .xfdo file will be neglected. RELNOTES: Build support for enabling cross binary FDO optimization. PiperOrigin-RevId: 199501260
* Simplify CppCompileAction#discoverInputs().Gravatar lberki2018-06-05
| | | | | | | | | | | | | | In the process, make it so that running an extra action attached to a CppCompileAction does not change the state of the CppCompileAction (yes, this happened: if include scanning was not done, topLevelModules would be changed) There are two changes in behavior this will: introduce 1. topLevelModules will no longer be set if include scanning is not in effect, but that's okay: it's never read except when shouldPruneModules is true, and if that is true, #discoverInputsStage2() will set it. 2. Extra actions attached to CppCompileAction will not get .pcm files on their inputs that were not used by the compiler RELNOTES: None. PiperOrigin-RevId: 199285276
* Remove --glibc optionGravatar rosica2018-06-04
| | | | | | | Crosstool selection will be based solely on --cpu and --compiler options. RELNOTES: Option --glibc is removed, toolchain selection relies solely on --cpu and --compiler options. PiperOrigin-RevId: 199156131
* C++: Makes JavaWrapCc use CcLinkingHelperGravatar plf2018-06-04
| | | | | | | It doesn't use CcLinkParamsStore and CppLinkAction directly anymore. RELNOTES:none PiperOrigin-RevId: 199107747
* Move TARGET_CPU from the CcToolchainProvider to BuildConfiguration.Gravatar jcater2018-06-01
| | | | PiperOrigin-RevId: 198877280
* C++: Remove CcSpecificLinkParamsProvider.Gravatar plf2018-06-01
| | | | | | No longer needed since proto_library cannot be used for Java. PiperOrigin-RevId: 198859993
* Modify cc_toolchain_suite rule to allow selection of cc_toolchain label ↵Gravatar rosica2018-05-30
| | | | | | | | | | | | | | | | without reading the CROSSTOOL file. As we want to reroute selecting the toolchain from CROSSTOOL through cc_toolchain, cc_toolchain_suite should have all the necesarry information for obtaining the cc_toolchain label without accessing the CROSSTOOL file. In order to do that, besides the existing <toolchain.targetCpu>|<toolchain.compiler>, we add <cpu> type of key in 'toolchains' attribute of cc_toolchain_suite. Now the selection of cc_toolchain label goes as follows: 1. Return toolchains[<cpu>|<compiler> if it exists 2. Return toolchains[<cpu>] if it exists 3. Fall back to the previous state: return toolchains[<toolchain.targetCpu>|<toolchain.compiler>] RELNOTES: None. PiperOrigin-RevId: 198588849
* C++: Hide compilation context from SkylarkGravatar plf2018-05-30
| | | | | RELNOTES:none PiperOrigin-RevId: 198518792
* Propagate --experimental_prune_cpp_input_discovery to host builds. Otherwise,Gravatar Googler2018-05-29
| | | | | | | host builds don't profit from it. RELNOTES: None. PiperOrigin-RevId: 198437467
* Avoid unnecessary work in validating C++ inclusions. Specifically:Gravatar Googler2018-05-29
| | | | | | | | | | | | | | - declaredIncludeSrcs don't need to be looked at as they also become part of the compilation prerequisites (see CcCompilationContext.addDeclaredIncludeSrc()) - transitiveModules can never be "incorrect" as they get computed and added by Bazel itself. - declaredIncludeDirs/warnIncludeDirs can be computed lazily. As most people aim for a warning-free build, it is rarely necessary to compute either set in practice. RELNOTES: None. PiperOrigin-RevId: 198386262
* Add CcSysrootAliasRuleGravatar dbabkin2018-05-29
| | | | | RELNOTES:none PiperOrigin-RevId: 198364550
* Remove CppCompileAction.optionalSourceFileGravatar hlopko2018-05-28
| | | | | | | It's unused. RELNOTES: NONE. PiperOrigin-RevId: 198316668
* Don't create a HashSet/Map just to copy them into the Immutable-counterpartGravatar Googler2018-05-28
| | | | | | | later. This wastes CPU cycles (directly and during GC). RELNOTES: None. PiperOrigin-RevId: 198302706
* Add an option --experimental_prune_cpp_input_discovery to stop C++ inputGravatar Googler2018-05-28
| | | | | | | | discovery at the boundary of modular headers. C++ modules generally should be self-contained and a using a C++ module doesn't require any of it's transitive source files to be present. PiperOrigin-RevId: 198299936
* Migrate cpp rules skylark objects to skylarkbuildapiGravatar cparsons2018-05-25
| | | | | RELNOTES: None. PiperOrigin-RevId: 198094324
* C++: Separates adding sources and private headers to CcCompilationHelperGravatar plf2018-05-25
| | | | | | | | This is part of a chain of CLs that will pull initialization of CcCompilationContext from CcCompilationHelper. RELNOTES:none PiperOrigin-RevId: 198060027
* Automated rollback of commit d62833f640690309e1a73aefa62de1d8821dc8ba.Gravatar plf2018-05-25
| | | | | RELNOTES:none PiperOrigin-RevId: 198025150
* For compilations with C++ modules, treat private headers (header files inGravatar Googler2018-05-23
| | | | | | | | | | | | | | | 'srcs') as textually included headers. A private header is never exported to a different module and thus cannot be used by a different module. We never need to compile a module just because one of it's private headers is used from somewhere else. There must be a different cc_library (and thus module) that exports the header. At the same time, being compiled into a module doesn't provide benefits for the compilation of that cc_library itself, because a module created for a cc_library A is never used when compiling any of A's srcs. PiperOrigin-RevId: 197846388
* Rename PatchTransition.apply to PatchTransiton.patch.Gravatar gregce2018-05-23
| | | | | | | This unclashes with the incoming ConfigurationTransition.apply method described in https://docs.google.com/document/d/1_UJKmAQ9EE8i3Pl0il3YLTYr-Q9EKYYyLatt2zohfyM/edit#heading=h.96gongkwg852. PiperOrigin-RevId: 197769784
* Restrict module usage to C++ actions. Other actions don't support compilingGravatar Googler2018-05-23
| | | | | | | | using C++ modules (yet) and thus we are paying some of the cost such as building transitive modules and a taller critical path without reaping any benefits. PiperOrigin-RevId: 197768129
* Remove FlagListGravatar hlopko2018-05-23
| | | | | | | This abstraction is not needed anymore. RELNOTES: None. PiperOrigin-RevId: 197739700
* C++: Expose additional methods for CcCompilationInfo and CcLinkingInfoGravatar plf2018-05-23
| | | | | | | This is needed for re-writing match_clif in Skylark. RELNOTES:none PiperOrigin-RevId: 197738067
* Windows: Fix link parameter file for dynamic linkingGravatar pcloudy2018-05-23
| | | | | | | | Related issue: https://github.com/bazelbuild/bazel/issues/1013 Fix https://github.com/bazelbuild/bazel/issues/5243 RELNOTES: PiperOrigin-RevId: 197715690
* Add a flag to disallow LIPO to aid in the rollout of the removal of LIPO ↵Gravatar lberki2018-05-23
| | | | | | | support. RELNOTES: None. PiperOrigin-RevId: 197708692
* Rename CcRunfiles fields one more time to be perfectly accurate.Gravatar hlopko2018-05-23
| | | | | RELNOTES: None. PiperOrigin-RevId: 197707463
* Rename staticRunfiles and dynamicRunfiles in CcRunfilesGravatar hlopko2018-05-22
| | | | | | | | New names are dynamicLibrariesForLinkingStatically and dynamicLibrariesForLinkindDynamically respsectively. RELNOTES: None. PiperOrigin-RevId: 197579028
* Split user_link_flags from legacy_link_flagsGravatar hlopko2018-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The difference between them is that user_link_flags will stay after we remove legacy fields from the crosstool. This is an encore of https://github.com/bazelbuild/bazel/commit/2661abb96b1fe51fb726a63eb08698564a82eb20 after mitigating the memory regression. Original cl regressed 12mb (on a big enough internal project :): objsize chg instances space KB class name ------------------------------------------------------ 24 +0 190265 4459 KB com.google.common.collect.ImmutableMapEntry 40 +0 95154 3716 KB com.google.common.collect.RegularImmutableMap 47 -2 95154 2230 KB [Ljava.util.Map$Entry; 44 -1 95154 2230 KB [Lcom.google.common.collect.ImmutableMapEntry; 24 +0 95149 2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$MapVariables 16 +0 95149 1486 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$StringSequence 89 +0 3188 176 KB [B 64 -8 0 -743 KB com.google.devtools.build.lib.rules.cpp.LinkCommandLine 76 +0 -1918 -1323 KB [Ljava.lang.Object; 24 +0 -95149 -2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$SingleVariables ------------------------------------------------------ The reason was that before legacy_link_flags were the only build variable patched because of thinlto in CppLinkActionBuilder, so it used optimized SingleVariables subclass. With the split, the patched variables instance had 2 variables therefore it received the full blown Variables instance. That accounted for the ~7mb. The fix was to move the patching logic to the initial link variables creation and not to create patched variables at all. Now the regression is ~4.8mb, which is perfectly expected since I introduce another variable and this is the overhead of additional hashmap entry: objsize chg instances space KB class name ------------------------------------------------------ 24 +0 190418 4462 KB com.google.common.collect.ImmutableMapEntry 44 +1 31 1487 KB [Lcom.google.common.collect.ImmutableMapEntry; 16 +0 95149 1486 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$StringSequence 47 +0 31 744 KB [Ljava.util.Map$Entry; 89 +0 5723 315 KB [B 24 +0 5721 134 KB java.lang.String 64 -8 0 -743 KB com.google.devtools.build.lib.rules.cpp.LinkCommandLine 76 +0 -2387 -840 KB [Ljava.lang.Object; 24 +0 -95149 -2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$SingleVariables ------------------------------------------------------ I'll pay this dept back once we get rid of legacy crosstool fields (= removal of legacy_link_flags variable). RELNOTES: None. PiperOrigin-RevId: 197574153
* Remove special handling of SpawnActionContext in Executor/ActionExecContextGravatar ulfjack2018-05-22
| | | | | | | | Instead, internally look up the correct context by mnemonic. This simplifies all the callers. We still need a little bit of special casing when constructing the action context map. PiperOrigin-RevId: 197572357
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 13:13:25 +0000