aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp
Commit message (Collapse)AuthorAge
...
* Restructure the NestedSet usage in CcCompilationContext. Goals:Gravatar Googler2018-07-10
| | | | | | | | | | | | | | | | | | - Don't use NestedSets of NestedSets. Not sure whether this is a performance improvement or has serialization benefits, but it does make understanding the structure a lot easier. - Use the same large NestedSet for all header information (whether or not they are modular and what pregrepped headers might exist). This speeds up the include scanner calls getLegalGeneratedScannerFileMap and getModularHeaders because they now iterate over just a single NestedSet and the second evaluation of a NestedSet is much cheaper. In a subsequent change, we can likely fold all three iterations over this NestedSet into one (in getLegalGeneratedScannerFileMap, getModularHeaders and getUsedModules). Measurements show a small reduction in heap usage. RELNOTES: None. PiperOrigin-RevId: 203909308
* [Reland] Accept proto paths relative to proto_source_root as direct ↵Gravatar Googler2018-07-09
| | | | | | | | | | | | | | | dependencies. This is a reland of https://github.com/bazelbuild/bazel/commit/5deca4cf88f5568771f2c836a9b8c693b88bd749. This will make protoc see as direct dependencies the .proto files that were included using the proto_source_root flag. Until now, Bazel passed to protoc the direct dependencies of a target as the path relative to the WORKSPACE, which made it fail when a shorter path, relative to the package was used. Progress on #4544. RELNOTES: None. PiperOrigin-RevId: 203808292
* Adds interning to CcToolchainVariablesGravatar shahan2018-07-09
| | | | | | This entails adding equality to all VariableValue subclasses. PiperOrigin-RevId: 203796225
* Windows, CROSSTOOL: Fix feature for linking interface library and dynamic ↵Gravatar pcloudy2018-07-09
| | | | | | | | | | library 1. Do not apply /WHOLEARCHIVE to interface library 2. On Windows, we cannot link dll directly, so remove related flag_groups RELNOTES: None PiperOrigin-RevId: 203752406
* Cleanup libs_to_link_dont_emit_objects_for_archiver build variableGravatar hlopko2018-07-06
| | | | | | | It's no longer needed. RELNOTES: None. PiperOrigin-RevId: 203469119
* Don't unnecessarily create a NestedSet and remove a stale comment. We do ↵Gravatar Googler2018-07-06
| | | | | | | want to use input discovery when building modules for performance reasons. RELNOTES: None. PiperOrigin-RevId: 203463009
* Add an experimental option to disable .d-file scanning for modular builds. WhenGravatar Googler2018-07-06
| | | | | | | | | | | building with C++ modules, .d file scanning is not effective as Clang (only compiler supporting Bazel's version of C++ modules) reads all of the files passed in anyway. This is not meant to be activated yet, but for running experiments. RELNOTES: None. PiperOrigin-RevId: 203459168
* Make C++ extra action properly add module file flags for discovered C++Gravatar Googler2018-07-06
| | | | | | | modules. RELNOTES: None. PiperOrigin-RevId: 203454562
* Add sysroot variable to cc_common.create_link_variablesGravatar hlopko2018-07-05
| | | | | | | Before this cl the sysroot variable was not present, and that's a bug. RELNOTES: None PiperOrigin-RevId: 203346557
* Replace old option name with new --discard_orphaned_artifacts in tests.Gravatar ccalvarin2018-07-02
| | | | | | | Also remove batch in these same tests in favor of the new --nokeep_state_after_build RELNOTES: None. PiperOrigin-RevId: 203011055
* C++: Exposes C++ Skylark providers to BazelGravatar plf2018-07-02
| | | | | RELNOTES:none PiperOrigin-RevId: 202943806
* Add a flag to disable the parts of the Skylark API of the C++ configuration ↵Gravatar lberki2018-07-02
| | | | | | | | | that depend on BUILD/CROSSTOOL files. Also add @Deprecated tags for these methods and extract CppConfigurationSkylarkTest in a separate class so that it actually gets run (followup change with the explanation a-coming) RELNOTES: None. PiperOrigin-RevId: 202903559
* Deletes AutoCodec.PUBLIC_FIELDS strategy. Superseded by DynamicCodec.Gravatar shahan2018-06-29
| | | | PiperOrigin-RevId: 202704472
* C++: Adds ctx to cc_link_params creation.Gravatar plf2018-06-29
| | | | | | | | | | This is done so that we can check whether the current target can use the C++ Skylark API. Rolling forward: BlazeInvocationPolicy is not used in host configuration. We simply ignore host configuration and not give an error when we are building there. RELNOTES:none PiperOrigin-RevId: 202652552
* Automated rollback of commit 908682a743d5a1c31b17bc199f9003a6b00114b8.Gravatar mstaib2018-06-29
| | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks tests: b/110978519 *** Original change description *** C++: Adds ctx to cc_link_params creation. This is done so that we can check whether the current target can use the C++ Skylark API. RELNOTES:none PiperOrigin-RevId: 202643988
* C++: Adds ctx to cc_link_params creation.Gravatar plf2018-06-29
| | | | | | | | This is done so that we can check whether the current target can use the C++ Skylark API. RELNOTES:none PiperOrigin-RevId: 202632582
* Deduplicate loose paths much earlier so that they create smaller nested setsGravatar Googler2018-06-28
| | | | | | and avoid needlessly copying lists. PiperOrigin-RevId: 202504396
* Change label from //tools/defaults:crosstool to //tools/cpp:crosstool",Gravatar dbabkin2018-06-28
| | | | | | RELNOTES:none PiperOrigin-RevId: 202483718
* Delete some more LIPO crumbs.Gravatar Benjamin Peterson2018-06-28
| | | | | | | Closes #5478. Change-Id: I3ac44605ef16a7c2e6bdc63d26fdf968bef651aa PiperOrigin-RevId: 202482493
* Remove CROSSTOOL_LABEL label resolver from ObjcRuleClasses.Gravatar dbabkin2018-06-28
| | | | | | | | Make ObjcRuleClasses uses CppRuleClasses.ccToolchainAttribute label resolver. Mark CppRuleClasses.ccToolchainAttribute with @AutoCodec annotation. RELNOTES:none PiperOrigin-RevId: 202479836
* Expose Skylark API to the C++ toolchainGravatar hlopko2018-06-28
| | | | | | | | | | | | | This is an implementation of the design at https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit>. More thorough documentation will be sent in a separate cl. The api was approved at https://docs.google.com/document/d/1M8JA7kzZnWpLZ3WEX9rp6k2u_nlwE8smsHYgVTSSJ9k/edit?ts=5b292400#. Work towards #4571 (only the docs are missing). RELNOTES: None. PiperOrigin-RevId: 202464331
* Add Interners for CcToolchainFeatures$ActionConfig, Feature, andGravatar mjhalupka2018-06-27
| | | | | | FeatureConfiguration. PiperOrigin-RevId: 202363333
* Automated refactor of Label.parseAbsolute() to always pass a repository mappingGravatar dannark2018-06-27
| | | | | RELNOTES: None PiperOrigin-RevId: 202360925
* C++: Makes Skylark CcCompilationInfo accept headersGravatar plf2018-06-27
| | | | | | | | | The Skylark constructor of CcCompilationInfo now accepts headers. This may be the last piece needed to get a working prototype of foreign C++ libraries. Next step would be open sourcing the sandwich. RELNOTES:none PiperOrigin-RevId: 202306252
* Instead of depending on mutable inputs of upstream CppCompileAction instances,Gravatar shahan2018-06-26
| | | | | | | | | CppCompileAction.discoverInputsStage2 retrieves values of discovered modules from ActionExecutionValue. This addresses a possible a correctness issue. PiperOrigin-RevId: 202162180
* Remove support for header preprocessingGravatar hlopko2018-06-26
| | | | | | | This was never used. We thought it will be useful, but it's not. RELNOTES: None. PiperOrigin-RevId: 202143524
* C++: Refactor WrapCcHelper.Gravatar plf2018-06-26
| | | | | | | Makes it non-instantiable so that it's easier to migrate SWIG rules to Skylark. RELNOTES:none PiperOrigin-RevId: 202136054
* Allow private headers to appear in directory artifactsGravatar hlopko2018-06-26
| | | | | | | | | | | | | | Before, Bazel expected that it can compile whatever appeared in cc_library.srcs directory artifacts. That is true for C/C++ source files, and for headers when the C++ toolchain supported header parsing/processing (which used CppCompileAction). When the toolchain doesn't support header parsing/processing, Bazel would crash. Addresses issue #5092. One part of it. Fixes #5372. RELNOTES: None. PiperOrigin-RevId: 202114286
* C++: Remove call to initializeCcCompilationContext.Gravatar plf2018-06-26
| | | | | | | | | To get a CcCompilationInfo instance from Skylark it will either have to be through its constructor (not yet fully implemented) which will not schedule any actions or through a call to compile() which does schedule actions. RELNOTES:none PiperOrigin-RevId: 202099841
* C++: Remove unnecessary runfiles providers.Gravatar plf2018-06-25
| | | | PiperOrigin-RevId: 201969238
* C++: Remove CcLinkParamsStore parameter from CcLinkingInfo.Gravatar plf2018-06-25
| | | | | | | | | | I will remove the CcLinkParamsStore class in a separate CL. For now, make sure the API doesn't expose this class. The only Skylark use was in cc_import which is migrated in this CL. RELNOTES:none PiperOrigin-RevId: 201948058
* ToolchainContext directly implements SkylarkValue and SkylarkIndexable.Gravatar John Cater2018-06-22
| | | | | Change-Id: I355b138e143771fd826ab03951df821ea7d58ac5 PiperOrigin-RevId: 201740564
* Expose aspect actions from Skylark.Gravatar tomlu2018-06-22
| | | | | | | | | | | Like with providers, consumers get a merged view of all actions from the merged configured target (all other aspects + the base target). I had to rejig the aspect value / configured aspect to be symmetric with rule configured targets. I do not expect significant memory bloat from this. All lists / maps already existed, only extra fields have been added. RELNOTES: Expose aspect actions provider to Skylark. PiperOrigin-RevId: 201697923
* Audit usages of Label.getRelative and update to Label.getRelativeWithRemappingGravatar dannark2018-06-21
| | | | | RELNOTES: None PiperOrigin-RevId: 201617188
* Add binfiles to quoted include directories for C++ compilationGravatar hlopko2018-06-21
| | | | | | | | | | | | | | | The only non-deprecated way to declare new files in Skylark is using ctx.actions (https://docs.bazel.build/versions/master/skylark/lib/actions.html). And these files are created in binfiles (there is one way to generate a file in Skylark in genfiles: a rule can be tagget with 'output_to_genfiles = True' attribute, but that forces all files of all actions in the rule to be generated in genfiles. And this attribtue is deprecated). Similarly, https://github.com/bazelbuild/bazel/commit/6c2f499b21e36c59d7da5e8b2e6c9b1804a36c64 added binfiles for <> includes when using cc_library.includes attribute. RELNOTES: None. PiperOrigin-RevId: 201504199
* Extract logic from CROSSTOOL in CrosstoolInfo providerGravatar rosica2018-06-21
| | | | | | | | | CrosstoolInfo carries the necessary information from the CROSSTOOL text proto. Later on, instead from the CROSSTOOL file and the corresponding CToolchain, CrosstoolInfo will be derived from a skylark_crosstool rule implemented in Skylark. Therefore CToolchain involvement in CppConfiguration and CcToolchain creation needs to be eliminated. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 201491207
* Add a minimum_os_version flag that is platform agnostic.Gravatar Googler2018-06-20
| | | | | | | | | | | | | | This corresponds to the os version in the clang target triple, though clang does have corresponding os_version_min flags for Apple platforms. Currently, Bazel has --XX_minimum_os flags for XX values corresponding to Apple platforms. This flag is the generic version of that (and can and will be set after the Apple split transition, and will eventually be set in the Android split as well) to support various Android API level improvements for native code. PiperOrigin-RevId: 201453961
* Don't instrument files generated by cc_proto_library for coverageGravatar Googler2018-06-20
| | | | | RELNOTES=None PiperOrigin-RevId: 201365986
* C++: Re-writes cc_import in Skylark.Gravatar plf2018-06-20
| | | | | | | I will put cc_import.bzl in Bazel in a follow up CL. RELNOTES:none PiperOrigin-RevId: 201332133
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 21:05:13 +0000