Build failure when using 0.1.47

[LPardue]

Hello!

I've just noticed a build failure in quiche CI related to CMAKE and noticed the crate had been bumped up to 0.1.47. See https://github.com/cloudflare/quiche/runs/4719660403?check_suite_focus=true

I tested pinning the commit to 0.1.46 and the builds go green again. https://github.com/cloudflare/quiche/runs/4719853406?check_suite_focus=true

Is there anything needed to be done by crate users to support 0.1.47? Or perhaps there some kind of breakage that has happened?

[alexcrichton]

Given the changes it's probably #136. I don't know enough about cmake to know why that would impact your build.

[LPardue]

Thanks for the response, understood. Hope that by creating the issue we perhaps attract someone that can figure it out or at least document a solution if we find it ourselves.

[jyn514]

I just found that CMAKE_SYSTEM_PROCESSOR is unset when cmake is passed -DCMAKE_SYSTEM_NAME (regardless of the value it's set to, not just "Linux"). Our build fails because it depends on SYSTEM_PROCESSOR being set.

I'm not sure exactly what #136 is trying to do, but given that it cause other bugs, maybe it makes sense to revert it? cc @messense

[jyn514]

Ah, this looks relevant: https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html

CMAKE_SYSTEM_NAME may be set explicitly when first configuring a new build tree in order to enable cross compiling. In this case the CMAKE_SYSTEM_VERSION variable must also be set explicitly.

I can confirm that SYSTEM_VERSION is unset when passing -DCMAKE_SYSTEM_NAME to cmake. Unfortunately setting SYSTEM_VERSION explicitly doesn't cause cmake to pick up SYSTEM_PROCESSOR, I guess the cmake-rs crate would have to define that too.

[jyn514]

Another alternative to completely reverting #136 is to only set CMAKE_SYSTEM_NAME when cross-compiling, not unconditionally when the target is linux.