This is an archive of the discontinued LLVM Phabricator instance.

[clang][Darwin] Try to guess the SDK root with xcrun when unspecified
AbandonedPublic

Authored by ldionne on Sep 8 2021, 1:01 PM.

Details

Reviewers
arphaman
Summary

On Apple platforms, the base system does not contain headers (e.g. in /usr/include).
As a result, one needs to point Clang to those headers manually when running it,
which can be cumbersome. Instead, if the SDK root can't be inferred with the
usual logic (using the SDKROOT env var), try to guess it by running 'xcrun'.

This should provide a default that's sane most of the time when running clang
without impeding the ability for users to select the SDK of their choice with
the usual means.

http://llvm.org/PR45880

Diff Detail

Event Timeline

ldionne requested review of this revision.Sep 8 2021, 1:01 PM
ldionne created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptSep 8 2021, 1:01 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

@arphaman This is a WIP patch -- I'm trying to see whether this idea is good or just bad from the start.

To summarize, people have been complaining (e.g. here) that Clang on Darwin doesn't work out of the box, because we don't ship headers in /usr/include. This is an attempt to provide a sane default by running xcrun --show-sdk-path from within Clang when no SDK root can be found otherwise.

I was pretty sure this was a good idea until I implemented it and then noticed the tests failing. Previously, when no SDK can be found (which is the case in most Clang tests since we don't run with xcrun), we would use whatever deployment target Clang defaults to. After this patch, however, we'll often find a SDK even though none is specified, and that will have the effect of setting a different deployment target than the one we expect in those tests. Do you think that is just a sign that this whole idea of trying to infer the SDK using xcrun is broken from the start, or those tests should simply be fixed?

I guess another option would be that if the target is specified, we try to infer the SDK path using xcrun --sdk <sdk-inferred-from-target> --show-sdk-path. That's starting to be complex, but it might solve some of these issues.

hans added a subscriber: hans.Sep 9 2021, 1:59 AM
thakis added a subscriber: thakis.Sep 9 2021, 4:31 AM

This is a nice idea.

One drawback is that if you don't pass -isysroot, things just wouldn't work before but now every clang invocation will call xcrun, so things will work but will be slower than if you passed -isysroot. But the convenience for one-off invocations is probably worth this subtlety.

Tests must be hermetic, so we should have some flag to disable this behavior and expand %clang and %clang_cc1 to pass the disable flag, to make sure tests don't rely on this.

Independent of tests, can we make the driver look at the triple and pass a matching -sdk flag to xcrun?

Also, on my system xcrun prints different paths depending on if I pass -sdk for some reason:

% xcrun -show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
% xcrun -show-sdk-path -sdk macosx
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk

I have to do -isysroot $(xcrun -show-sdk-path -sdk macosx) for things to work. That's another point in favor of passing an -sdk flag.

ormris removed a subscriber: ormris.Jan 24 2022, 11:46 AM

I'm interested in this feature--is there any reason this wasn't completed? If not, I might be able to take over implementing this.

Herald added a project: Restricted Project. · View Herald TranscriptOct 15 2022, 3:44 PM
Herald added a subscriber: MaskRay. · View Herald Transcript

I'm interested in this feature--is there any reason this wasn't completed? If not, I might be able to take over implementing this.

Lack of bandwidth. It would be awesome if someone took this over.

ldionne abandoned this revision.Oct 20 2022, 5:22 AM

Abandoning in favor of D136315.

keith added a subscriber: keith.Oct 20 2022, 11:40 AM