[cmake-developers] CMAKE_SYSROOT vs CMAKE_OSX_SYSROOT

[Brad King]

On 07/11/2013 10:41 AM, clinton at elemtech.com wrote:
> They also appear similar to me, so I would start with the
> assumption that they should be unified.

I just dug into this a bit.

One difference is that CMAKE_OSX_SYSROOT can be set to a logical
SDK name rather than a path.  In Darwin.cmake there is code to
transform it to a path by running

 xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path

If we unify the two we will need to find a way to handle this.

The value of CMAKE_OSX_SYSROOT is not used in any CMake modules
outside of Darwin.cmake (and an old reference in Darwin-icc.cmake
that should probably be refactored anyway).  It is used in only
three C++ sources:

* cmCoreTryCompile.cxx: The value of CMAKE_OSX_SYSROOT is passed
  into the build of the test project for a try-compile.  This
  will probably be needed for CMAKE_SYSROOT too.

* cmGlobalXCodeGenerator.cxx: The value of CMAKE_OSX_SYSROOT is
  used to set the generated Xcode SDKROOT attribute.  The SDKROOT
  can be a logical name or a path but IIUC the logical name is
  preferred.  Xcode uses it to add the -isysroot flag.

* cmLocalGenerator.cxx: The value of CMAKE_OSX_SYSROOT is used
  to add the -isysroot flags for generators besides Xcode (since
  Xcode uses the SDKROOT attribute).

It looks to me like CMAKE_SYSROOT and CMAKE_OSX_SYSROOT are
pretty much identical other than the logical name mapping.
At a minimum we need to make them mutually exclusive (at most
one can be set in a single build tree).  Ideally we should
combine them so that one only needs to set CMAKE_SYSROOT on
any platform.

Combining them is safe only if we're sure CMAKE_SYSROOT will
not be used for anything besides the toolchain system SDK.

For compatibility on OS X we can use the old CMAKE_OSX_SYSROOT
when CMAKE_SYSROOT is not set.  Along with an error when both are
set we should be able to make a smooth transition even without
a policy.  Can anyone else think of complications?

-Brad