|
From: | 陈北宗 |
Subject: | Re: Forking on Github and feedback |
Date: | Wed, 9 Dec 2015 21:51:50 +0800 |
The decision of deprecating gnustep-make is from its fundamental incompatibility with stepcode-build which takes an Xcode project file. Either stepcode-build have to be written using no GNUstep at all, we allow stepbuild-build to conflict with gnustep-make, or we have a dependency loop at our hands if libobjc and CoreBase depend on it to build. I don't think you will find it appropriate to build a bootstrap version of stepcode-build with a static version of Apple's CoreFoundation and then rebuild it linking against our own. This is the reason I am proposing moving libobjc2 and CoreBase to pure Cmake or plain Makefile so stepcode-build can depend on it. Or if you are so in love with gnustep-make, can you guys make it understand Xcode spec files which are at heart NeXT-style plists? In fact, the reason of rewriting TFB also have something to do with stepcode-build as with the rewritten CoreBase will have effectively half of Base inside, allowing stepcode-build to be written in Objective-C ARC with Base headers yet without linking against Base. And this allows the rest of Base to be built with stepcode-build. The copying of headers can be done using a plain Makefile. Apple have long reversed their decision of optional CALayer for UI elements since at least iOS 2.0 - every UIView is backed by a CALayer. In my plan of GUI rewrite the same principal applies to NSView and NSCell too since it reduces the graphics back ends to support down to one: OpenGL. This allow us to deprecate gnustep-back entirely, emit more efficient graphics code, and be Wayland-ready. And paths? That is up to Mesa (and in turn, GPU) if the path is going to the display. Sent from my iPhone
|
[Prev in Thread] | Current Thread | [Next in Thread] |