aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CcToolchain.java
Commit message (Collapse)AuthorAge
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-02
| | | | PiperOrigin-RevId: 195094385
* Ensure make variables from the CcToolchainProvider end up in theGravatar jcater2018-04-24
| | | | | | TemplateVariableInfo. PiperOrigin-RevId: 194088329
* Make the constructor of TemplateVariableInfo available in Skylark.Gravatar lberki2018-04-24
| | | | | | RELNOTES[NEW]: TemplateVariableInfo can now be constructed from Skylark. PiperOrigin-RevId: 194072452
* 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
* Implement absolute_path_profile attribute to fdo_profile rule along with an ↵Gravatar Googler2018-04-13
| | | | | | | | | | | | | | | | | option to disable it This attribute allows fdo_profile to accept profiles under absolute path. It can be disabled with --enable_fdo_profile_absolute_path=false. Example: fdo_profile( name = "fdo_profile", absolute_path_profile = "/absolute/path/to/profile.profraw" ) RELNOTES: Introduce absolute_path_profile attribute that allows fdo_profile to accept absolute paths. PiperOrigin-RevId: 192763631
* Make --fdo_optimize paths be PathFragment instead of Path, and remove the ↵Gravatar Googler2018-04-11
| | | | | | now unused ConfigurationEnvironment#getBlazeDirectories() PiperOrigin-RevId: 192443323
* Implement fdo_profile rule for architecture-sensitive fdo profile specificationGravatar Googler2018-04-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fdo_profile rule allows specifying architecture-sensitive fdo profiles. This is especially important in multi-architecture builds. Currently the profiles can only be labels of input files, but later on a way to support absolute files for profiles will be added. Example: fdo_profile( name = "profile", profile = select({ ":k8" : "//path/to/some/profile.zip", ":ppc": "//path/to/some/other/profile.afdo", }), ) config_setting( name = "k8", values = { "cpu": "k8", }, ) config_setting( name = "ppc", values = { "cpu": "ppc", }, ) RELNOTES: Introduce fdo_profile rule that allows architecture-sensitive specification of fdo profiles. PiperOrigin-RevId: 192125371
* 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
* Remove CcToolchainProvider#getEnvironment() and all the supporting ↵Gravatar lberki2018-04-03
| | | | | | | | | | | infrastructure. This was added in unknown commit to provide a different environment to Apple toolchains, then its use removed in unknown commit in favor of getting the environment variables from the CToolchain proto. I haven't done my research if that's a better approach, but it looks like it (the less hard-coded stuff we have in Java, the better), but worst of all is surely to have *two* such mechanisms. RELNOTES: None. PiperOrigin-RevId: 191411878
* PiperOrigin-RevId: 189372237Gravatar Googler2018-03-16
|
* Add a helper method for checking whether toolchain resolution is enabled for ↵Gravatar John Cater2018-03-13
| | | | | | | | | a toolchain type. Closes #4832. Change-Id: Ia4fce6dd7003dc441f81ea7ca65ce865ca222142 PiperOrigin-RevId: 188882041
* 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
* Allow cc_toolchain to have inline proto toolchain data, instead of using ↵Gravatar John Cater2018-03-02
| | | | | | | crosstool top. Change-Id: I531034b0c991d18b05818db4b40cbd739535b565 PiperOrigin-RevId: 187617580
* CcToolchain: add optional ar and as attributesGravatar Googler2018-02-22
| | | | | | | | These may be used to retrieve the ar and as programs associated with the compiler toolchain. RELNOTES: None. PiperOrigin-RevId: 186626548
* 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
* @AutoCodec some c++ linking data structures.Gravatar cpeyser2018-02-20
| | | | PiperOrigin-RevId: 186314781
* 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
* Route --fdo_optimize information through an implicit dependency instead of ↵Gravatar Googler2018-02-13
| | | | | | | CppConfiguration RELNOTES: None. PiperOrigin-RevId: 185527875
* 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
* C++: Refactors CLIF rule to go through CcLibraryHelper.Gravatar plf2018-01-26
| | | | | | | | | | | TBD: finish pulling out CLIF logic from the C++ rules implementation. This involves refactoring ArtifactCategory and CppSource.Type. CLIF does PIC compilation now. This detail should be irrelevant to users since CLIF only cares about the matched protobuf output file. SKIP_KOKORO=flakes RELNOTES:none PiperOrigin-RevId: 183396902
* Adds a CODEC for CppConfiguration.Gravatar shahan2018-01-10
| | | | | | | * Creates an enum for cpu transformer, which is easier to serialize than an opaque function. This also means moving FakeCPU to avoid introducing a circular dependency. * Adds a CODEC to Path using InjectingObjectCodec. PiperOrigin-RevId: 181445911
* Enable switching def_parser's Windows target for remote executionGravatar Yun Peng2018-01-02
| | | | | | | | | | | | When --define EXECUTOR=remote is specified in bazel command, embedded tools 'def_parser' will be compiled remotely from source. Because def_parser itself is a cc_binary, if we want to compile it remotely, to avoid cycle dependency it cannot be a dependency of cc_toolchain. Therefore, we make it a dependency of cc rules. Change-Id: I77faf77238f8edd3585d0e5e5c780b14e9782a40 PiperOrigin-RevId: 180534568
* 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
* Move CppConfiguration#getFullyStaticLinkOptions, #getMostlyStaticLinkOptions,Gravatar cpeyser2017-11-28
| | | | | | | | | | | and #getDynamicLinkOptions to CppHelper. This allows toolchain information needed by those methods to move to CcToolchainProvider. The migration of toolchain information from CppConfiguration to CcToolchainProvider is required to move the c++ rules to platform-based toolchain selection. PiperOrigin-RevId: 177230635
* 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'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
* 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
* Change default behavior for cc_toolchain.compiler and cc_toolchain.libc forGravatar cpeyser2017-11-18
| | | | | | | | platform-based toolchain selection to match legacy behavior. This is a change over previous behavior in the platform case, which was to throw if either of those attributes is not present. The default_toolchain field in CROSSTOOL gives a mapping from cc_toolchain.cpu values to toolchains - this map should be used with compiler and libc are not specified, as is currently the non-platforms, legacy behavior. PiperOrigin-RevId: 176246316
* Move CppConfiguration#getBuiltinIncludeDirectories to CcToolchainProvider.Gravatar cpeyser2017-11-14
| | | | PiperOrigin-RevId: 175682806
* toolchain_type can export make variables from the toolchain instead of theGravatar cpeyser2017-11-13
| | | | | | configuration. PiperOrigin-RevId: 175532550
* 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#getHostSystemName, #getTestOnlyLinkOptions, ↵Gravatar cpeyser2017-11-06
| | | | | | #getObjCopyOptionsForEmbedding, #getLdOptionsForEmbedding and #getDefaultSysroot to CcToolchainProvider. PiperOrigin-RevId: 174508128
* Move CppConfiguration#toolchainNeedsPic, #getRuntimeSysroot, andGravatar cpeyser2017-10-31
| | | | | | #getSolibDirectory to CcToolchainProvider. PiperOrigin-RevId: 174032021
* Migrate CppConfiguration#supportsGoldLinker, supportsDynamicLinker,Gravatar cpeyser2017-10-31
| | | | | | supportsEmbeddedRuntimes, supportsExecOrigin to CcToolchainProvider. PiperOrigin-RevId: 173928009
* 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 CppConfiguration#getStaticRuntimeLibsLabel and #getDynamicRuntimeLibsLabelGravatar cpeyser2017-10-25
| | | | | | to CcToolchainProvider. PiperOrigin-RevId: 173301847
* Expose a CcToolchainProvider that is generated by the legacy toolchain ↵Gravatar cpeyser2017-10-23
| | | | | | selection logic to skylark. PiperOrigin-RevId: 172921818
* Make cc_toolchain put the files comprising the toolchain into its FileProvider.Gravatar lberki2017-10-18
| | | | | | | Note that cc_toolchain_suite is not changed this way, but that rule doesn't currently serve as a proxy for cc_toolchain (unlike java_runtime_suite for java_runtime), so that's OK. RELNOTES: None. PiperOrigin-RevId: 172502279
* In CppToolchainInfo, use the label of the cc_toolchain instead of ↵Gravatar cpeyser2017-10-16
| | | | | | --crosstool_top to find the crosstool package. PiperOrigin-RevId: 172320513
* Replace all tool getters in CppConfiguration with corresponding calls toGravatar cpeyser2017-10-12
| | | | | | CcToolchainProvider#getToolPathFragment. PiperOrigin-RevId: 171837541
* Migrate usage of CppConfiguration#getToolPathFragment andGravatar cpeyser2017-10-11
| | | | | | CppConfiguration#getLdExecutable to CcToolchainProvider. PiperOrigin-RevId: 171818406
* Add 'compiler' and 'libc' attributes to cc_toolchain. If platform/toolchainGravatar cpeyser2017-09-28
| | | | | | | resolution is used, use these attribute values to choose a CToolchain from --crosstool_top instead of --compiler and --glibc. PiperOrigin-RevId: 170217186
* 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
* 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
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* 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
* 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
* Support multiple command lines / params files in SpawnAction.Gravatar tomlu2017-09-15
| | | | | | This is necessary for the upcoming Skylark implementation of param files. PiperOrigin-RevId: 168744486
* Zipped LLVM multi-arch profiles is now supported.Gravatar Googler2017-09-15
| | | | | RELNOTES: None. PiperOrigin-RevId: 168703540
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 16:13:30 +0000