Uh oh!
There was an error while loading. Please reload this page.
Rename CLR_CMAKE_HOST_ARCH CLR_CMAKE_PLATFORM_ARCH - #1887
Conversation
hoyosjs
left a comment
There was a problem hiding this comment.
I prefer the term host for being more explicit. However, I am not married to this. @jkoritzinsky and @janvorli would have more context between the terms
jkoritzinsky
commented
Jan 17, 2020
I think platform works better than host if we ever were to cross-build something that works with another arch (for example, a Linux x86 crossgen that outputs Linux ARM32 native code built on a Linux x64 machine). In this scenario, these would be the definitions of the terms:
In most if not all of our cases today, Host == Platform. |
hoyosjs
commented
Jan 17, 2020
Good point. Fair then.
I guess only ARM/ARM64 cross compiles? |
janvorli
commented
Jan 17, 2020
x86 (once / if we start to build it) would cross-compile too. We have support for it in our rootfs building scripts and our customers are using it. |
jkotas
commented
Jan 18, 2020
We should stick to the definitions of terms that everybody else is using, so that people do not have to have a special decoder ring for our system: https://clang.llvm.org/docs/CrossCompilation.html Host: The os/build arch that the built code runs on |
Notice that nobody uses "platform" to name any of these 3. If "platform" is used, it is always with combination with other qualifier, e.g. "host platform" or "target platform". |
jkoritzinsky
commented
Jan 18, 2020
I’m good with matching clang and GCC. |
sdmaclea
commented
Jan 18, 2020
I'll close this and write the opposite patch... It'll be bigger... |
We were currently using both the term "Platform" and "Host" to refer to the architecture of the executing code. They both are distiguished from the "Target" which is the architecture of the debug target, or JIT target.
The term "Platform" is dominant in the code. This changes the HOST usages to PLATFORM before adding more complexity for cross OS compilation.