Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add explicit --sdk argument to xcrun calls #9371

Closed
wants to merge 1 commit into from

Conversation

keith
Copy link
Member

@keith keith commented Sep 11, 2019

Xcode 11 (and possibly earlier versions) has a bug where, when you don't
pass -sdk macosx, it can either pick the global
/Library/Developer/CommandLineTools SDK path, or the SDK path bundled
within Xcode itself. This seems to depend on if you have other versions
of Xcode installed, and which versions of the command line tools you
have installed. Passing -sdk macosx seems to always force it to pick
the Xcode bundled version, which is what we prefer. This fixes issues
with remote cache misses caused by these tools not being the same
because of this difference. At least 2 apple bugs have been filed
about this FB7147521 FB7253366

You can see which path it's picking by running:

env -i xcrun -l -n clang

@kastiglione
Copy link
Contributor

Since this affects cache, can it be picked into the next release (1.0)?

@DavidGoldman DavidGoldman self-assigned this Sep 11, 2019
@DavidGoldman
Copy link
Contributor

Should the flags be --sdk macosx instead? I don't see -sdk documented in man xcrun or xcrun --help

@keith keith changed the title Add explicit -sdk argument to xcrun calls Add explicit --sdk argument to xcrun calls Sep 12, 2019
@keith
Copy link
Member Author

keith commented Sep 12, 2019

@DavidGoldman updated!

@DavidGoldman
Copy link
Contributor

And then I think we should also update this

Xcode 11 (and possibly earlier versions) has a bug where, when you don't
pass `-sdk macosx`, it can either pick the global
`/Library/Developer/CommandLineTools` SDK path, or the SDK path bundled
within Xcode itself. This seems to depend on if you have other versions
of Xcode installed, and which versions of the command line tools you
have installed. Passing `-sdk macosx` seems to always force it to pick
the Xcode bundled version, which is what we prefer. This fixes issues
with remote cache misses caused by these tools not being the same
because of this difference.

You can see which path it's picking by running:

```
env -i xcrun -l -n clang
```
@keith
Copy link
Member Author

keith commented Sep 12, 2019

Updated and re-checked all the others, I don't think I missed anymore. There is this one that I think could be improved but it's not hit by this issue https://github.com/keith/bazel/blob/dcbd30ee9788231fc410848d7ad10da5bfca156f/src/tools/xcode/stdredirect/BUILD#L10-L12

@irengrig irengrig added the WIP label Sep 13, 2019
@bazel-io bazel-io closed this in ada2c55 Sep 13, 2019
dslomov pushed a commit that referenced this pull request Sep 16, 2019
Xcode 11 (and possibly earlier versions) has a bug where, when you don't
pass `-sdk macosx`, it can either pick the global
`/Library/Developer/CommandLineTools` SDK path, or the SDK path bundled
within Xcode itself. This seems to depend on if you have other versions
of Xcode installed, and which versions of the command line tools you
have installed. Passing `-sdk macosx` seems to always force it to pick
the Xcode bundled version, which is what we prefer. This fixes issues
with remote cache misses caused by these tools not being the same
because of this difference. At least 2 apple bugs have been filed
about this FB7147521 FB7253366

You can see which path it's picking by running:

```
env -i xcrun -l -n clang
```

Closes #9371.

PiperOrigin-RevId: 268906772
keith added a commit to keith/bazel that referenced this pull request Sep 18, 2019
This is a follow up to bazelbuild#9371
which helps maintain cache hits across different macOS versions. By
default when you compile something on macOS with clang the minimum OS
version is set to the current OS version. This means if you have
developers on multiple OS versions they may not get cache hits.
bazel-io pushed a commit that referenced this pull request Sep 18, 2019
This is a follow up to #9371
which helps maintain cache hits across different macOS versions. By
default when you compile something on macOS with clang the minimum OS
version is set to the current OS version. This means if you have
developers on multiple OS versions they may not get cache hits.

10.9 was chosen to match rules_apple bazelbuild/rules_apple@86ce425

Closes #9403.

PiperOrigin-RevId: 269817249
dslomov pushed a commit that referenced this pull request Sep 30, 2019
Xcode 11 (and possibly earlier versions) has a bug where, when you don't
pass `-sdk macosx`, it can either pick the global
`/Library/Developer/CommandLineTools` SDK path, or the SDK path bundled
within Xcode itself. This seems to depend on if you have other versions
of Xcode installed, and which versions of the command line tools you
have installed. Passing `-sdk macosx` seems to always force it to pick
the Xcode bundled version, which is what we prefer. This fixes issues
with remote cache misses caused by these tools not being the same
because of this difference. At least 2 apple bugs have been filed
about this FB7147521 FB7253366

You can see which path it's picking by running:

```
env -i xcrun -l -n clang
```

Closes #9371.

PiperOrigin-RevId: 268906772
dslomov pushed a commit that referenced this pull request Oct 2, 2019
Xcode 11 (and possibly earlier versions) has a bug where, when you don't
pass `-sdk macosx`, it can either pick the global
`/Library/Developer/CommandLineTools` SDK path, or the SDK path bundled
within Xcode itself. This seems to depend on if you have other versions
of Xcode installed, and which versions of the command line tools you
have installed. Passing `-sdk macosx` seems to always force it to pick
the Xcode bundled version, which is what we prefer. This fixes issues
with remote cache misses caused by these tools not being the same
because of this difference. At least 2 apple bugs have been filed
about this FB7147521 FB7253366

You can see which path it's picking by running:

```
env -i xcrun -l -n clang
```

Closes #9371.

PiperOrigin-RevId: 268906772
@keith keith deleted the ks/xcrun-sdk branch September 25, 2020 19:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants