aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/rules/cpp/CcToolchainProviderTest.java
Commit message (Collapse)AuthorAge
* Add flags for disabling legacy crosstool fieldsGravatar hlopko2018-07-17
| | | | | | | | | | | | This cl adds following flags: * --experimental_disable_legacy_cc_compilation_api * --experimental_disable_legacy_cc_linking_api * --experimental_disable_linking_mode_flags * --experimental_disable_compilation_mode_flags * --experimental_disable_legacy_crosstool_fields RELNOTES: None PiperOrigin-RevId: 204924599
* Expose new methods in CcToolchainProvider to eventually replace skylark ↵Gravatar juliexxia2018-06-14
| | | | | | callables that depend on CToolchain in CppConfiguration. PiperOrigin-RevId: 200559893
* 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
* 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
* 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
* Add @AutoCodec to CcToolchainProvider, now that AutoCodec Runtime is available.Gravatar cpeyser2018-02-23
| | | | PiperOrigin-RevId: 186789093
* Document ambigious literal arguments when calling CcToolchainProvider ↵Gravatar Googler2018-02-23
| | | | | | | constructor RELNOTES: None. PiperOrigin-RevId: 186744674
* 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
* 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
* 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
* 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
* toolchain_type can export make variables from the toolchain instead of theGravatar cpeyser2017-11-13
| | | | | | configuration. PiperOrigin-RevId: 175532550
* Expose a CcToolchainProvider that is generated by the legacy toolchain ↵Gravatar cpeyser2017-10-23
| | | | | | selection logic to skylark. PiperOrigin-RevId: 172921818
* 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
* 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
* 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
* Make CcToolchainProvider#equals() be the object identity.Gravatar lberki2017-07-11
That's the only way to provide sane behavior both in Skylark and in Java. RELNOTES: None. PiperOrigin-RevId: 161496153
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 09:48:05 +0000