-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop loading packages in CppConfiguration #6072
Comments
This is a preparation for a cl removing package loading from CppConfiguration. #6072. RELNOTES: None. PiperOrigin-RevId: 211453414
#6072. RELNOTES: None. PiperOrigin-RevId: 211455462
#6072. RELNOTES: None. PiperOrigin-RevId: 211464711
Currently FdoProfiler is provided by the cc_toolchain separately. This causes problems to custom skylark rules that store the implicit attribute as _cc_toolchain, and native rules store it as ':cc_toolchain'. And FdoProvider was expected to be provided by the ':cc_toolchain'. Since FdoProvider is used together with the CcToolchainProvider, I'm merging them together. #6072. RELNOTES: None. PiperOrigin-RevId: 211635916
Apart from slight moving of blocks of code nearer to where they are used, this cl does one major thing. Before: When we didn't find a label in cc_toolchain_suite.toolchains satisfying '--cpu|--compiler', we iterated over the CROSSTOOL and selected a CToolchain 'foo'. Then we used that 'foo.targetCpu|foo.compiler' to get the label from cc_toolchain_suite.toolchains to get the cc_toolchain 'bar'. So we used (foo, bar). After: After we find 'bar', and bar.toolchain_identifier is set, we select the CToolchain 'baz' from the CROSSTOOL matching that toolchain_identifier. Baz doesn't necessarily have to be the same as foo. So we use (foo, baz). #6072. RELNOTES: None. PiperOrigin-RevId: 211981401
They should be used during toolchain selection (will happen in unknown commit). I think it's an oversight that they are configurable now. #6072 RELNOTES: None PiperOrigin-RevId: 212791669
…ain in cc_toolchain Rather re-select the toolchain for yourself. The next step will be to stop relying on CROSSTOOL in the CppConfiguration. #6072. RELNOTES: None. PiperOrigin-RevId: 212813981
As a result, I could rewire CToolchain selection in CppConfigurationLoader.selectCcToolchainLabel to use the same entry point method as we do in the CppConfigurationLoader.createParameters and in CcToolchain.create, and simplify the code a bit. #6072 RELNOTES: None. PiperOrigin-RevId: 213258694
…lchain Use CcSkyframeSupportFunction instead. #6072 RELNOTES: None. PiperOrigin-RevId: 214004051
*** Reason for rollback *** Suspected breakage of perf regtest *** Original change description *** Do not depend on CppConfiguration to provide CROSSTOOL file to cc_toolchain Use CcSkyframeSupportFunction instead. #6072 RELNOTES: None. PiperOrigin-RevId: 214043149
…lchain Use CcSkyframeSupportFunction instead. #6072 This is a rollforward of unknown commit after fixing loading CROSSTOOL from different package roots. RELNOTES: None. PiperOrigin-RevId: 214394291
This is a preparation for a change moving CcToolchainProvider creation from CcToolchain to CcToolchainSuite. #6072. RELNOTES: None. PiperOrigin-RevId: 214589270
This is a preparation for moving CcToolchainProvider creation to the cc_toolchain_suite. This cl just moves code around to make the diff of the followup cl smaller. #6072. RELNOTES: None. PiperOrigin-RevId: 214624986
Is this going to help with |
Nope, it will only help with not loading C++ toolchain in the loading phase, only in the analysis phase (which is a prerequisite for migrating C++ rules to platforms). I'm not sure I know which issue are you referring to? |
This provider encapsulates everything that is cc_toolchain-rule specific and contributes to the construction of CcToolchainProvider. In the followup cl, cc_toolchain will be modified to provide CcToolchainAttributesProvider, and cc_toolchain_suite will get the provider and construct the CcToolchainProvider from it. #6072. RELNOTES: None. PiperOrigin-RevId: 214762144
I'm talking about this:
which produces
Full output here |
…c_toolchain_label_from_crosstool_proto Users commonly hit a problem when migrating their toolchains for this flag. Adding a paragraph to make them aware of the solution. #6072. RELNOTES: None. PiperOrigin-RevId: 215186089
This way, we don't have to do any package loading in the CppConfiguration (yay!). cc_toolchain now provides CcToolchainAttributesProvider, a lightweight representation of its attributes, and cc_toolchain_suite will select one and use it to create the full CcToolchainProvider. This cl should be backwards compatible under normal use, but there are some behavioral differences: * Before, cc_toolchain_suite was not analyzed * Before, only the selected cc_toolchain was analyzed * Now, cc_toolchain_suite is analyzed * Now, all cc_toolchains of the cc_toolchain_suite are analyzed #6072 RELNOTES: CppRules: All cc_toolchains depended on from cc_toolchain_suite.toolchains are now analyzed when not using platforms in order to select the right cc_toolchain. PiperOrigin-RevId: 216605275
This way, we don't have to do any package loading in the CppConfiguration (yay!). cc_toolchain now provides CcToolchainAttributesProvider, a lightweight representation of its attributes, and cc_toolchain_suite will select one and use it to create the full CcToolchainProvider. This cl should be backwards compatible under normal use, but there are some behavioral differences: * Before, cc_toolchain_suite was not analyzed * Before, only the selected cc_toolchain was analyzed * Before, cc_toolchain_alias returned cc_toolchain target (observable from aspects) * Now, cc_toolchain_suite is analyzed * Now, all cc_toolchains of the cc_toolchain_suite are analyzed * Before, cc_toolchain_alias returns cc_toolchain_suite target (observable from aspects) #6072 This is a roll-forward of 3aedb2f after adding an incompatible flag. RELNOTES: CppRules: All cc_toolchains depended on from cc_toolchain_suite.toolchains are now analyzed when not using platforms in order to select the right cc_toolchain. PiperOrigin-RevId: 218865033
This way, we don't have to do any package loading in the CppConfiguration (yay!). cc_toolchain now provides CcToolchainAttributesProvider, a lightweight representation of its attributes, and cc_toolchain_suite will select one and use it to create the full CcToolchainProvider. This cl should be backwards compatible under normal use, but there are some behavioral differences: * Before, cc_toolchain_suite was not analyzed * Before, only the selected cc_toolchain was analyzed * Before, cc_toolchain_alias returned cc_toolchain target (observable from aspects) * Now, cc_toolchain_suite is analyzed * Now, all cc_toolchains of the cc_toolchain_suite are analyzed * Before, cc_toolchain_alias returns cc_toolchain_suite target (observable from aspects) Progress on #6072 Fixes #6537 RELNOTES: None. PiperOrigin-RevId: 222289686
And with this I declare the issue fixed. |
Also remove special cache for crosstools, they are now fully managed by the Skyframe caches in the same way as any other file is managed. #6072 RELNOTES: None. PiperOrigin-RevId: 223147737
…ction #6072. RELNOTES: None PiperOrigin-RevId: 223312270
Tracking the effort to finally remove package loading from CppConfigurationLoader and CppConfiguration.
The text was updated successfully, but these errors were encountered: