[101141] trunk/dports/_resources/port1.0/group/cmake-1.0.tcl
Joshua Root
jmr at macports.org
Sat Jan 5 00:27:07 PST 2013
> Revision: 101141
> https://trac.macports.org/changeset/101141
> Author: jeremyhu at macports.org
> Date: 2013-01-04 23:21:56 -0800 (Fri, 04 Jan 2013)
> Log Message:
> -----------
> cmake: Ensure that CMAKE_OSX_DEPLOYMENT_TARGET is unset if CMAKE_OSX_SYSROOT is /
>
> This will avoid errors like the following when we don't use an sdkroot:
>
> CMake Error at /opt/local/share/cmake-2.8/Modules/Platform/Darwin.cmake:190 (message):
> CMAKE_OSX_DEPLOYMENT_TARGET is '10.8' but CMAKE_OSX_SYSROOT:
>
> "/"
>
> is not set to a MacOSX SDK with a recognized version. Either set
> CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to
> empty.
>
> Modified Paths:
> --------------
> trunk/dports/_resources/port1.0/group/cmake-1.0.tcl
>
> Modified: trunk/dports/_resources/port1.0/group/cmake-1.0.tcl
> ===================================================================
> --- trunk/dports/_resources/port1.0/group/cmake-1.0.tcl 2013-01-05 07:14:20 UTC (rev 101140)
> +++ trunk/dports/_resources/port1.0/group/cmake-1.0.tcl 2013-01-05 07:21:56 UTC (rev 101141)
> @@ -74,7 +74,7 @@
> if {${configure.sdkroot} != ""} {
> configure.args-append -DCMAKE_OSX_SYSROOT="${configure.sdkroot}"
> } else {
> - configure.args-append -DCMAKE_OSX_SYSROOT=/
> + configure.args-append -DCMAKE_OSX_SYSROOT=/ -DCMAKE_OSX_DEPLOYMENT_TARGET=""
I notice the uncommitted part of the patch in
<https://trac.macports.org/ticket/36857> does the opposite, i.e. removes
the addition of "-DCMAKE_OSX_SYSROOT=/" when configure.sdkroot is empty.
Does -DCMAKE_OSX_DEPLOYMENT_TARGET="" mean that MACOSX_DEPLOYMENT_TARGET
is not set when building? Doesn't it default to 10.4 (x86) or 10.1 (ppc)
in that case?
Does setting MACOSX_DEPLOYMENT_TARGET always cause cmake to want to use
an SDK, or only when it's not the same as the build system? The release
notes seem to be saying that it avoids using an SDK when it isn't
necessary. Is the error from Darwin.cmake then a leftover that doesn't
reflect the current behaviour?
- Josh
More information about the macports-dev
mailing list