build-tools icon indicating copy to clipboard operation
build-tools copied to clipboard

feat: Use DEVELOPER_DIR to set Xcode path without requiring sudo

Open itsananderson opened this issue 3 years ago • 1 comments

When you work on multiple projects with different Xcode versions, having e build invoke sudo xcode-select -s all the time get's annoying.

By setting DEVELOPER_DIR in e-build.js before calling e-load-xcode.js, we make xcode-select -p return the correct Xcode path, so e-load-xcode.js won't attempt to xcode-select -s as sudo. Subsequent subprocess calls to actually build Electron will also pick up that DEVELOPER_DIR variable, ensuring that the right Xcode version is used.

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ e build
Running "e load-xcode --quiet"
Running "ninja -j 200 electron" in /Users/<user>/electron/master/src/out/Testing
[21/21] STAMP obj/electron/electron.stamp

If you actually want to persist the selection change, you can still call e load-xcode directly.

 $ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ e load-xcode
Setting your Xcode installation to /Users/<user>/.electron_build_tools/third_party/Xcode/Xcode.app, this will require sudo
Password:
SUCCESS

$ xcode-select -p
/Users/<user>/.electron_build_tools/third_party/Xcode/Xcode.app/Contents/Developer

Fixes #416

itsananderson avatar Sep 16 '22 18:09 itsananderson

I think this would supersede #323, so CC'ing @MarshallOfSound since he had opinions in that PR

ckerr avatar Sep 16 '22 22:09 ckerr

I think this would supersede #323, so CC'ing @MarshallOfSound since he had opinions in that PR

I don't think this PR currently solves the goals of that PR, but it could probably be modified to do so.

One solution would be to allow DEVELOPER_DIR variable to be added to your env config, and if it's present, build-tools would use that path rather than overriding it with ~/.electron_build_tools/third_party/Xcode/Xcode.app/Contents/Developer. This way you could force build-tools to use a newer version of Xcode that build-tools doesn't know about yet. The drawback is that build-tools would no longer verify that you're using the right Xcode version, but I guess that's kind of the objective of overriding with your system Xcode.

itsananderson avatar Sep 17 '22 02:09 itsananderson

This doesn't currently supersede #323 and I still think #323 isn't what we want.

MarshallOfSound avatar Sep 17 '22 22:09 MarshallOfSound

I've moved the DEVELOPER_DIR env var to depot-tools.js so now it should apply to any child processes spawned via that mechanism.

@MarshallOfSound what would you think of me removing the xcode-select -s code from e-load-xcode.js? It's redundant with the DEVELOPER_DIR logic now, so the only reason I can think of for keeping it is in case someone wants to explicitly call e load-xcode to permanently select the build-tools version of Xcode.

The advantage of removing it (or alternatively putting it behind a --no-select flag when invoked from e-build) is that it would actually make a workaround for #323 possible. Someone who needs to use a bleeding-edge version of Xcode could do so by by specifying a custom DEVELOPER_DIR variable in their evm config.

itsananderson avatar Sep 20 '22 00:09 itsananderson