Makes it easy to change Command Line Tools (like by
using DEVELOPER_DIR) without changing/getting influenced
by PATH etc.
I just searched COMMAND in the code. LMK if there are other
invocations on macOS that should be done via xcrun.
Details
Details
- Reviewers
Brecht Van Lommel (brecht) - Group Reviewers
Platform: macOS
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- xcrun (branched from master)
- Build Status
Buildable 13771 Build 13771: arc lint + arc unit
Event Timeline
Comment Actions
Is this solving a specific problem you encountered?
If we need to e.g. use xcrun xcode-select or xcrun xcodebuild to solve some specific problem, that seems reasonable.
But it's not obvious to me that in general adding this to as many commands as possible is helpful.
| CMakeLists.txt | ||
|---|---|---|
| 576 | As far as I can tell from verbose build output, CMake does not use xcrun ${CMAKE_CXX_COMPILER}. So this could lead to a mismatch rather than solving a problem? | |
| build_files/build_environment/cmake/options.cmake | ||
| 134 | uname is not a development tool affected by xcrun. | |
| build_files/cmake/platform/platform_apple_xcode.cmake | ||
| 84 | pkgutil is not a development tool affected by xcrun. | |
Comment Actions
If we need to e.g. use xcrun xcode-select or xcrun xcodebuild to solve some specific problem, that seems reasonable.
In platform_apple.cmake, instead of [checking for Xcode, and if it fails resorting to /Library CLTs], xcrun could directly choose the appropriate CLTs as per the environment variables. It also does all the heavy lifting of finding the SDK in the CLTs.
Noticed that while working on D10838: WIP attempt to set CMAKE_OSX_SYSROOT before project call.
But it's not obvious to me that in general adding this to as many commands as possible is helpful.
Indeed it's not. It'd also add some time penalty.. see the speed of xcrun date vs `date.
Comment Actions
But which problem is this solving?
Did you actually find situation where xcodebuild and xcrun xcodebuild do something different?