CMP0083 PIE policy warnings for executables are noisy
Opening this issue to discuss CMP0083 after trying out CMake 3.14.0-rc2 on some larger projects. It is likely to be common for projects to set CMAKE_POSITION_INDEPENDENT_CODE to true, which will act as a default for all targets. In the past, this worked well and ensured that even if you built static libraries, those could be linked in by shared libraries and the shared library was able to be PIC. Because we didn't have PIE linker flags correct, executables simply came out as non-PIE but no warning was generated. It was not explicit that they should have been PIE anyway.
With CMake 3.14, we now try to make an executable PIE if its POSITION_INDEPENDENT_CODE target property is set to NEW and we also require the project to have called
check_pie_supported() from the new
CheckPIESupported module, which was also introduced in 3.14. If CMP0083 is unset (which will generally be the case, at least in the medium term for many projects), having CMAKE_POSITION_INDEPENDENT_CODE set to true will now start warning about every executable, even test code. This is very noisy and the choices a project faces for reducing the noise are currently not very attractive:
Stop defining CMAKE_POSITION_INDEPENDENT_CODE and manually set POSITION_INDEPENDENT_CODE on all the libraries where it might be relevant. This could be a lot of work and might not even be something that a project can do (it may not be able to do it for all of its dependencies, for example). If we rely on this, then we are basically saying to stop using CMAKE_POSITION_INDEPENDENT_CODE altogether.
Explicitly set the policy to NEW and accept that executables that may not need to be PIE will become PIE. Tests don't typically need to be, for example, but they would become PIE with this strategy. The performance cost of PIE seems to be small from what I understand (I've seen numbers like 2% thrown around back when researching the merge request for the PIE work), but I don't know if that's always going to be representative. I'm also not sure whether it will always be possible to force the CMP0083 policy to NEW down through dependencies without resorting to fairly hacky methods (e.g. setting the CMAKE_POLICY_DEFAULT_CMP0083 variable to NEW), since the policy will get reset with every
CheckPIESupported module is being introduced in the same CMake version and therefore no existing project would be using it, I wonder if we could use that module as an added condition on whether we issue a warning or not. If the
check_pie_supported() function hasn't been called, then assume the project never intended for executables to be PIE and just leave the behavior at that with no warning. If that function has been called, that function enforces that CMP0083 must be set to NEW at the point of that call and we know at that point that something in the project actively wants to have PIE support. Unfortunately, we still get defeated by
cmake_minimum_required() resetting our CMP0083 policy again, so such a change would only be of benefit until something somewhere in the build started enabling PIE executables by calling
check_pie_supported(), but I suspect that's still a pretty significant proportion of projects.