Does DEVELOPER_DIR need to remain set in the environment?

Question

I'd like to have side-by-side installations of XCode, and use the DEVELOPER_DIR environment variable to select between them. The goal for this is to use the result of xcrun -f --sdk macosx clang to determine the appropriate C compiler, and then use that in a script or build system.

CC=$(DEVELOPER_DIR=<something> xcrun -f --sdk macosx clang)

My question is whether DEVELOPER_DIR needs to remain set when using the tools found by xcrun, or whether it is OK to just set it during the execution of xcrun, as is done above, and then use the returned tools in the default environment, without DEVELOPER_DIR still set.

In other words, while xcrun clearly does depend on the value of DEVELOPER_DIR, do the tools themselves depend on it too? Is there a meaningful difference between:

• DEVELOPER_DIR=<whatever> command CC=$(xcrun -f --sdk macosx clang)
• command CC=$(DEVELOPER_DIR=<whatever> xcrun -f --sdk macosx clang)

Is the second one correct? Or only the first?

Answer 1

I'd like to have side-by-side installations of XCode, and use the DEVELOPER_DIR environment variable to select between them.

It's fine to have two or more versions of Xcode installed. The usual way to select between them is to use the xcode-select command, but the man page for that command does seem to say that you can accomplish the same thing for just the current session by setting the DEVELOPER_DIR environment variable yourself. Here's what the documentation for the --switch option says:

Sets the active developer directory to the given path, for example /Applications/Xcode-DP.app. This command must be run with superuser permissions (see sudo(8)), and will affect all users on the system. To set the path with-out superuser permissions or only for the current shell session, use the DEVELOPER_DIR environment variable instead (see ENVIRONMENT).

However, you should also heed the advice given in the ENVIRONMENT section:

Note that for historical reason, the developer directory is considered to be the Developer content directory inside the Xcode application (for example /Applications/Xcode.app/Contents/Developer). You can set the environment variable to either the actual Developer contents directory, or the Xcode application directory -- the code-select provided shims will automatically convert the environment variable into the full Developer content path.

So the <whatever> in your question should specify the full path to the Developer directory, not just to the Xcode application.

In other words, while xcrun clearly does depend on the value of DEVELOPER_DIR, do the tools themselves depend on it too? Is there a meaningful difference between:

• DEVELOPER_DIR=<whatever> command CC=$(xcrun -f --sdk macosx clang)

Using xcrun to find the tools so that you can invoke them yourself and worrying about when to set and unset DEVELOPER_DIR seems overly complicated. Per the xcode-select documentation, all the "shims" respect the DEVELOPER_DIR setting. "Shims" here refers to the Xcode commands in /usr/bin. As long as that environment variable is set correctly, you can just invoke '/usr/bin/clang' instead of whatever xcrun finds, and /usr/bin/clang will call through to the clang version in DEVELOPER_DIR. Presumably, you're asking this question because you're writing a build script of some kind, so there should be no problem setting DEVELOPER_DIR early in that script and then just using the /usr/bin commands.

• command CC=$(DEVELOPER_DIR=<whatever> xcrun -f --sdk macosx clang)

Programs inherit the environment from their parent processes. Here you're finding the right copy of clang to use, but you'll invoke it in an environment where DEVELOPER_DIR isn't set. Whether this matters depends on whether the tool you're using invokes any other tools. I honestly don't know whether any of the tools do invoke other tools, but it seems logical that a tool like xcodebuild would invoke many of those tools and therefore depend on DEVELOPER_DIR being set correctly.

In short, there's no downside to setting DEVELOPER_DIR as needed in your build script, and trying to specify it only in your call to xcrun seems less reliable in general than the alternative approach.