You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding setting a default value in the environment for CMAKE_TOOLCHAIN_FILE, I’m actually not convinced it’s the best solution. Consider projects that need to build some executables with the “normal” gcc compiler, and then use the resulting executables in the cross build [1]. Setting a default for CMAKE_TOOLCHAIN_FILE in this case will break the part that needs the normal gcc. We would need to unset the env var before running cmake to build the first part, and then setting the env var back before building the second part. This is also the reason why I haven’t overridden the CC and CXX env vars in the image: some parts of the build may want the normal gcc, and some other parts the cross gcc. I think it’s best that each part explicitly declares which compiler it wants, for example by passing the CMAKE_TOOLCHAIN_FILE argument for CMake projects, or setting the CXX variable, etc.
As you’ve mentioned, having such a behavior differ from the oecore toolchain means both toolchains need to be handled differently. This may not be desirable. But the oecore behavior is really not ideal for projects having a dual-compiler layout.
[1] I have encountered such cases before. This can be used for example to generate some code that is used for the second half of the build.
No description provided.
The text was updated successfully, but these errors were encountered: