Yeah it all makes much more sense now. I was so stuck in the terminal I completely forgot there even was an Xcode project.
So I’ll submit a patch making the python script farm out to xcodebuild instead of trying to configure a Mac. > On 18 May 2016, at 16:35, Philippe Hausler <phaus...@apple.com> wrote: > > Yea, the python build scripts only work on Linux. Before the initial drop I > was tinkering with making it build both but the Xcode project was just > simpler and easier to maintain. Either use xcodebuild or use the Xcode IDE > instead of the ninja builders. > > It might be nice one day to unify the Linux and Darwin builds. Per the name > of Foundation versus SwiftFoundation it sidesteps the potentials of getting > confused with the system version (since they are not replaceable due to > object layouts among other things). > > Sent from my iPhone > >> On May 18, 2016, at 7:24 AM, Karl <razie...@gmail.com> wrote: >> >> To clarify: xctest tries to build Foundation using xcodebuild. Actually, I >> wonder why it didn’t use xcodebuild the first time. >> >> Maybe it should. Maybe that’s the way out of this. >> >>> On 18 May 2016, at 16:21, Karl <raziel.im+swift-us...@gmail.com> wrote: >>> >>> OSX 10.11.4, latest Xcode and SDKs. >>> >>> The Swift compiler is correct here - the CF header has an availability >>> attribute, but the Foundation symbol doesn’t. Either the Foundation symbol >>> needs to become less available, or the CF one needs to become more >>> available. >>> >>> I bypassed it by removing the restrictions from CF, but then I had a >>> problem at link time: CFRuntime has hardcoded symbols which require the >>> module name to be “SwiftFoundation”, but it’s defined (right at the top of >>> build.py) as being “Foundation” (and it’s always been like that since the >>> first commit). So I don’t know what’s correct - the hardcoded symbols, >>> which say it’s ‘SwiftFoundation’, or the build script, which has always >>> called it just ‘Foundation’. I don’t see how it ever compiled and linked on >>> OSX. >>> >>> That’s not all, either - there’s a clang bug (since version 5 apparently) >>> which causes it to emit calls to its own ___udivti3 builtin which it can’t >>> resolve, so you need to add a clang-specific hack to disable 128-bit >>> division in CFBigNum or it also won't link. >>> >>> After you do that, you can finally create libFoundation.dylib. >>> Unfortunately, I tried to build xctest afterwards. If you called the module >>> ‘Foundation’, it’ll fire up xcodebuild, which fails with those missing >>> symbols from CFRuntime - this time it wants them to be called >>> “SwiftFoundation”. So am I supposed to build it as SwiftFoundation? Okay, >>> so I did that. >>> >>> I don’t remember if xctest compiled fully (I don’t think it did...), then I >>> disabled it, and tried to build swiftpm instead. I managed to get most of >>> the way through that, but then it failed while trying to link ‘swift_build’ >>> because the link directory <foundation build dir>/Foundation didn’t exist >>> (of course it doesn't; it’s called SwiftFoundation now!). >>> >>> So now I’m just feeling like I opened a can of worms. >>> >>> >>>> On 18 May 2016, at 15:56, Philippe Hausler <phaus...@apple.com> wrote: >>>> >>>> We are keeping the CoreFoundation sources in sync with the one that is >>>> skipped with your SDK and the one running on your system. >>>> >>>> What version of Mac OS X are you running? What version of the SDK do you >>>> have? I have a feeling that a combination of those two may be the reason >>>> for those errors. >>>> >>>> Sent from my iPhone >>>> >>>>> On May 18, 2016, at 4:44 AM, Karl via swift-dev <swift-dev@swift.org> >>>>> wrote: >>>>> >>>>> I’m trying to fix Foundation on OSX (or am I doing something wrong? I was >>>>> surprised to find it didn’t build) >>>>> >>>>> I’ve run in to a problem, though: swift is telling me that certain APIs >>>>> are not available: >>>>> >>>>>> Foundation/NSNumberFormatter.swift:19:70: error: 'ordinalStyle' is only >>>>>> available on OS X 10.11 or newer >>>>>> internal let kCFNumberFormatterOrdinalStyle = >>>>>> CFNumberFormatterStyle.ordinalStyle >>>>>> ^ >>>>>> Foundation/NSNumberFormatter.swift:19:70: note: add @available attribute >>>>>> to enclosing let >>>>>> internal let kCFNumberFormatterOrdinalStyle = >>>>>> CFNumberFormatterStyle.ordinalStyle >>>>>> ^ >>>>> >>>>> That’s because the CoreFoundation headers have availability declarations >>>>> on them. >>>>> It obviously doesn’t make sense for us to keep them (and for the >>>>> resulting swift Foundation project to inherit them), because we’re >>>>> building a toolchain and defining all of those symbols, not linking >>>>> against the system versions. >>>>> >>>>> So in order to build CoreFoundation/Foundation for OSX, we’d need to >>>>> remove these declarations from the headers. Is there any problem with >>>>> that? Are they synced to anything at Apple HQ? >>>>> >>>>> Thanks >>>>> >>>>> Karl >>>>> _______________________________________________ >>>>> swift-dev mailing list >>>>> swift-dev@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-dev >> _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
