build: add private frameworks directory to Darwin's native paths #23166
Conversation
| @@ -86,6 +86,7 @@ pub fn detect(arena: Allocator, native_target: std.Target) !NativePaths { | |||
| if (std.zig.system.darwin.isSdkInstalled(arena)) sdk: { | |||
| const sdk = std.zig.system.darwin.getSdk(arena, native_target) orelse break :sdk; | |||
| try self.addLibDir(try std.fs.path.join(arena, &.{ sdk, "usr/lib" })); | |||
| try self.addFrameworkDir(try std.fs.path.join(arena, &.{ sdk, "System/Library/PrivateFrameworks" })); | |||
There was a problem hiding this comment.
I don't think it's a good idea to include PrivateFrameworks by default.
There was a problem hiding this comment.
Could you explain why? I still think having the build system look first in frameworks and then in private frameworks under the native SDK path is a good default.
There was a problem hiding this comment.
The private framework is not meant to be used by developers, if developers want to use it anyway, they need to set the required paths all by themselves.
For example clang don't include the private framework path by default.
There was a problem hiding this comment.
Private frameworks can be used by developers. They are called private because App Store apps aren't allowed to use them, only Apple apps are. See: https://theapplewiki.com/wiki/Filesystem:/System/Library/Frameworks
Public frameworks are allowed to be used in App Store apps. Private frameworks are intended to be used only by Apple's apps, and are more unstable against firmware changes, but many of the interesting features are in the private frameworks.
What shouldn't be done is searching for frameworks under root, instead of the Xcode SDKs path, which is the source of our confusion in #17017.
There was a problem hiding this comment.
But I see how this might be a workaround for the fact that zig is unable to find frameworks under root, while clang seems to be able to.
There was a problem hiding this comment.
I'm against this.
It's not a good idea to default search the SDK private frameworks. Apple intentionally put it aside for reasons, and if it must be used, it needs to be opt-in. This is consistent with Xcode's clang, and Xcode's GUI.
iirc, if one needed to add this to enable SDK private frameworks search in Xcode, it would be adding a framework dir based on SDKROOT variable.
Both zig and clang command line do not have any such mechanism to add search paths relative to SDK (to my knowledge).
If zig were to support such a thing, the proper place for it is probably using the zig build system and one opts-in there. But in thinking about a possible impl, zig doesn't expose the SDKROOT as detected in lib/std/zig/system/darwin.zig. For clarity, SDKROOT is the result of command line xcrun --show-sdk-path.
|
Makes sense. I'll close this one then. Thanks for the input everyone. |
Closes #17017
To avoid confusion as to what the correct private framework search path is, add it by default. This ordering keeps the original Frameworks path as the first one to be searched.