On 04/29/2014 11:01 AM, Brad King wrote:
Xcode: Use sysroot and deployment target to identify compiler
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cce556b
Okay, that worked.
I've reverted my change to the machine-specific dashboard
script.
Since Tests/CMakeLists.txt is still
On 04/30/2014 09:19 AM, Brad King wrote:
Since Tests/CMakeLists.txt is still processed by the older
CMake used to run the dashboard it still detects GNU as the
compiler id and activates this test. Then the test fails
because it is hard-coded to support only GNU and not Clang
or AppleClang.
On 04/28/2014 01:07 PM, Brad King wrote:
It looks like in this case users will have to tell Xcode what tool
to use up front using the CMake generator toolset feature (cmake -T).
I think this is acceptable because it only affects old Xcode versions.
Otherwise we will need a much more
On Tuesday, April 29, 2014 11:01:06 AM Brad King wrote:
On 04/28/2014 01:07 PM, Brad King wrote:
It looks like in this case users will have to tell Xcode what tool
to use up front using the CMake generator toolset feature (cmake -T).
I think this is acceptable because it only affects old
On 04/26/2014 08:55 AM, Stephen Kelly wrote:
Stephen Kelly wrote:
Could this be because it is old clang which did not define __clang__?
Apart from the misidentification, I don't understand how the
WriteCompilerDetectionHeader test could have a different result than the
compiler
Hi,
This causes the failure of the WriteCompilerDetectionHeader test:
http://open.cdash.org/testDetails.php?test=250378767build=3306874
Though the misidentification has been the case since before that
refactoring:
http://open.cdash.org/testDetails.php?test=247853583build=3293163
Could
Stephen Kelly wrote:
Could this be because it is old clang which did not define __clang__?
Apart from the misidentification, I don't understand how the
WriteCompilerDetectionHeader test could have a different result than the
compiler identification code. It should be checking the same
