![]() xcode-select simply provides a way of manipulating some configuration on the system that libxcselect will make use of when one of these shim commands is run, or if xcrun is invoked directly by the user with specific options. Remember that this checking is the responsibility of libxcselect. The libxcselect library linked to by xcode-select (the same linked to by the git shim binary we showed earlier) has a series of configuration checks it will perform to try and auto-discover a developer directory, and assuming it finds one, xcode-select -p will tell us what that is.īelow are what I’ve deduced its order of checks to be. You can then use the -s/-switch option to change this path.Ĭhances are you’ve worked on a machine where you’ve never had to run xcode-select -s to explicitly select a directory, and other times you have. Applications/Xcode-7.2.app/Contents/Developer How directories are auto-selectedĬheck the currently selected directory with xcode-select using the -p/-print-path option. That being said, I’d like to know if there is a case where the CLI tools provided with Xcode apps are insufficient and the separate CLI tools package is required because it provides something not included with Xcode. However, if a system at some point has either been switched to a different developer dir, an Xcode app was moved, or Xcode itself has been recently upgraded (silently, from the Mac App Store, and a new license has yet to be accepted, for example), one might reason that both Xcode and CLI tools are required for some tasks, when this shouldn’t be the case. In my experience Xcode always contains the full set of CLI tools. So, it’s often the case that one might end up with both an Xcode and the CLI tools package installed, and at some point there may be confusion about when one is required over the other. In some cases, native extensions in packages for other languages like Ruby and Python also require Xcode. The CLI tools are sufficient for providing some common developer tools, but they don’t include the SDKs or xcodebuildneeded to build Xcode projects. The CLI tools from this package live in /Library/Developer/CommandLineTools. ![]() ![]() Not every use case calls for a full Xcode installation, and the CLI tools are a tiny fraction of the install footprint of Xcode. Starting in OS X 10.9, Apple began making it very easy to get the CLI tools installed on-demand. Xcode apps include a Developer directory at Contents/Developer within the app bundle, where among many other things, all the command line tools are installed. Look for the _xcrun_shim segment in the _DATA section output by the command: pagestuff /usr/bin/xcrun -a.) Developer directories (If all of this isn’t yet enough indirection for you, /usr/bin/xcrun itself is a shim, and so libxcselect.dylib contains code to detect whether the executed xcrun is a shim. xcode-select will error that it’s an invalid directory. Try for yourself: temporarily rename usr/lib/libxcrun.dylib within a developer dir like /Library/Developer/CommandLineTools and then try to xcode-select -switch to it. libxcrun.dylib is a hard requirement for a developer dir to be validated, however. The xcrun binary seems to be present in developer directories included with Xcode but not the CLI tools, and it’s also able to query information about SDKs and their included tools. One part of this process is to check whether this path contains usr/lib/libxcrun.dylib, and the xcrun tool, in which case it will invoke xcrun to run the binary. What’s really going on when we call these shim binaries?īehind the scenes, if I run /usr/bin/git, this shim binary loads functions in libxcselect.dylib that can locate the path to the real binary, depending on how the system has been configured. ![]() usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0 ) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1 )
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |