Responses inline: > On Dec 29, 2015, at 5:03 AM, Luke Howard <lu...@padl.com> wrote: > > OK, so I’ve cleaned up the commit history for the NSCoding branch, you can > find it here still: > > https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding > <https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding> > > I haven’t opened a pull request as I’d like to get it working on Linux first. > Having a bit of trouble though. (I’m using Ubuntu 15.10 with the latest > snapshot.) > > Firstly, build-wise: > > * Changing anything in Foundation/ seems to trigger a recompile of everything > Swift. Is there a way to do correct dependency analysis? My clock is OK.
Yep; probably should be a “known issue” the ninja script will emit the other swift files as deps since there might be cross file dependencies - it is a bit slow when the compiler is in debug mode > > * swift/utils/build-script with —debug-foundation still seems to build a > release version. I worked around by building everything debug, but that takes > up a lot of disk space. My trick that I do is I will build a release build and then hand edit the `.configuration` file of Foundation to be debug; so that way the next `ninja reconfigure` will reconfig it as debug and give juicy debugging info but the rest of the runtime and compiler is in release mode. (I have been considering adding this as a specialized reconfigure option > > * lldb crashes all the time when printing variables (actually I also see this > on OS X as well with the snapshot) po or p? > > Related to testing: > > * Something weird is going on with casting over which completely breaks > NSKeyedArchiver. I can reproduce it with the following: > > let foo = (NSMutableArray() as? AnyObject) as? NSCoding > > which the compiler tells me always succeeds (as I believe it should), but at > runtime returns foo==nil. No issue if it is a locally defined class that > conforms to NSCoding. It’s failing in _dynamicCastToExistential()’s check for > _conformsToProtocols() but I haven’t dug deeper yet. > > FYI: my LD_LIBRARY_PATH is pointing to the right libswiftCore/libFoundation. > I removed the module maps for Foundation/CoreFoundation from the snapshot > directory. The removal of the module map is usually only needed when building directly to an installed root. Most of the build process for incremental builds don’t need to have module map removal shenanigans. > > * Subclassing NSObject fails outside Foundation (see SR-272) is also an issue > but not a blocking one > > — Luke
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
