[PATCH] D13605: [CMake] [Darwin] Add support for generating Xcode-compatible toolchains that xcodebuild and xcrun can search

[Chris Bieneman via llvm-commits]

> On Oct 14, 2015, at 12:28 AM, Justin Bogner <mail at justinbogner.com> wrote:
> 
> Chris Bieneman via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> writes:
>> beanz created this revision.
>> beanz added a reviewer: Bigcheese.
>> beanz added a subscriber: llvm-commits.
>> 
>> Sometimes you want to install a custom compiler and use it like the
>> system compiler without overriding the system compiler. This patch
>> lets you create xctoolchains that the darwin command line tools can
>> use.
> 
> This is really useful. A couple of comments below, but this basically
> LGTM.
> 
>> To use this patch set LLVM_CREATE_XCODE_TOOLCHAIN=On in your CMake
>> invocation and build the `install-code-toolchain` target.
>> 
>> After installation you can set the envar EXTERNAL_TOOLCHAINS_DIR to
>> your installed Toolchains directory, and the TOOLCHAINS envar to the
>> toolchain identifier (ex org.llvm.3.8.0svn). This will then cause
>> /usr/bin/clang to call your newly installed clang.
>> 
>> http://reviews.llvm.org/D13605
>> 
>> Files:
>>  tools/xcode-toolchain/CMakeLists.txt
>> 
>> Index: tools/xcode-toolchain/CMakeLists.txt
>> ===================================================================
>> --- /dev/null
>> +++ tools/xcode-toolchain/CMakeLists.txt
>> @@ -0,0 +1,62 @@
>> +# OS X 10.11 El Capitan has just been released. One of the new features, System
>> +# Integrity Protection, prevents modifying the base OS install, even with sudo.
>> +# This prevents LLVM developers on OS X from being able to easily install new
>> +# system compilers. The feature can be disabled, but to make it easier for
>> +# developers to work without disabling SIP, this file can generate an Xcode
>> +# toolchain. Xcode toolchains are a mostly-undocumented feature that allows
>> +# multiple copies of low level tools to be installed to different locations, and
>> +# users can easily switch between them.
>> +
>> +# Setting an environment variable TOOLCHAINS to the toolchain's identifier will
>> +# result in /usr/bin/<tool> or xcrun <tool> to find the tool in the toolchain.
>> +
>> +# To make this work with Xcode 7.1 and later you can install the toolchain this
>> +# file generates anywhere on your system and set EXTERNAL_TOOLCHAINS_DIR to the
>> +# path specified by $CMAKE_INSTALL_PREFIX/Toolchains
>> +
>> +# This file generates a custom install-xcode-toolchain target which constructs
>> +# and installs a toolchain with the identifier in the pattern:
>> +# org.llvm.${PACKAGE_VERSION}. This toolchain can then be used to override the
>> +# system compiler by setting TOOLCHAINS=org.llvm.${PACKAGE_VERSION} in the
>> +# in the environment.
>> +
>> +if(NOT APPLE)
>> +  return()
>> +endif()
>> +
>> +option(LLVM_CREATE_XCODE_TOOLCHAIN "Create a target to install LLVM into an Xcode toolchain" Off)
>> +
>> +if(NOT LLVM_CREATE_XCODE_TOOLCHAIN)
>> +  return()
>> +endif()
>> +
>> +execute_process(
>> +  COMMAND xcodebuild -find clang
> 
> I'd probably use `xcrun -find` rather than `xcodebuild -find`. Not that
> it makes much of a difference.

Sure. It doesn’t make any functional difference. If I understand correctly xcrun just calls xcodebuild.

> 
>> +  OUTPUT_VARIABLE clang_path
>> +  OUTPUT_STRIP_TRAILING_WHITESPACE
>> +  ERROR_FILE /dev/null
>> +)
>> +string(REGEX MATCH "(.*Toolchains).*" toolchains_match ${clang_path})
> 
> Seems slightly safer/clearer to match "(.*/Toolchains)/.*”

Will update.

> 
>> +if(NOT toolchains_match)
>> +  message(FATAL_ERROR "Could not identify toolchain dir")
>> +endif()
>> +set(toolchains_dir ${CMAKE_MATCH_1})
>> +
>> +set(XcodeDefaultInfo "${toolchains_dir}/XcodeDefault.xctoolchain/ToolchainInfo.plist")
> 
> What happens if you've already installed the custom toolchain? I guess
> $toolchains_dir will point to $EXTERNAL_TOOLCHAINS_DIR and this will
> fail.

True. I can work around that by changing the xcrun line to look for a tool that won’t reasonably exist in the external toolchain (like otool). Then even if TOOLCHAINS and EXTERNAL_TOOLCHAINS_DIR are set it will find the tool in the XcodeDefault toolchain.

-Chris

> 
>> +set(LLVMToolchainDir "${CMAKE_INSTALL_PREFIX}/Toolchains/LLVM${PACKAGE_VERSION}.xctoolchain/")
>> +
>> +add_custom_command(OUTPUT ${LLVMToolchainDir}
>> +                    COMMAND ${CMAKE_COMMAND} -E make_directory ${LLVMToolchainDir})
>> +
>> +add_custom_command(OUTPUT ${LLVMToolchainDir}/ToolchainInfo.plist
>> +                  DEPENDS ${LLVMToolchainDir}
>> +                  COMMAND ${CMAKE_COMMAND} -E copy "${XcodeDefaultInfo}" "${LLVMToolchainDir}/ToolchainInfo.plist"
>> +                  COMMAND /usr/libexec/PlistBuddy -c "Set:Identifier org.llvm.${PACKAGE_VERSION}" "${LLVMToolchainDir}/ToolchainInfo.plist")
>> +
>> +add_custom_target(install-xcode-toolchain
>> +                  DEPENDS ${LLVMToolchainDir}/ToolchainInfo.plist
>> +                  COMMAND "${CMAKE_COMMAND}" --build ${CMAKE_BINARY_DIR} --target all
>> +                  COMMAND "${CMAKE_COMMAND}"
>> +                          -DCMAKE_INSTALL_PREFIX=${LLVMToolchainDir}/usr/
>> +                          -P "${CMAKE_BINARY_DIR}/cmake_install.cmake"
>> +                  ${cmake_3_2_USES_TERMINAL})

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151015/5de802f6/attachment.html>