gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forking on Github and feedback


From: 陈北宗
Subject: Re: Forking on Github and feedback
Date: Fri, 4 Dec 2015 23:10:03 +0800

1) and 2) can get covered by uname-detecting and a little bit of command line art, and the rest get covered by clang. If a platform does not run clang, there is no point making GNUstep work there either, and this clang precondition pretty much means Linux and Windows only, and this already covered 99% of user base. Meanwhile, we do need an AArch64 objc_msgSend.
4) I need dispatch-io in CoreBase and Base, and don’t forget XPC…
13) CG is full of CF classes and objects. Try this:

CGPathRef path = CGPathCreateWithRect(CGRectZero, NULL);
id path_objc = CFBridgingRelease(path);
NSLog(@address@hidden, path_objc.description);

14) Spec files will be supported, plugin will be supported but compatibility is a maybe.
15) The Wayland-based graphics stack requires the client program to talk directly to Mesa over EGL so just like Qt, Clutter or GTK+ we have to speak EGL as well, or include yet another dependency (going against my intention of deprecating Back). EGL being a 3D API does not mean we cannot implement 2D on top of it. And I may end up implementing SpriteKit first as a “2D-on-EGL” layer and build the rest of Quartz2D on top of that. X11 is already on its slow way out so I am not going to make a dependency there.

On Dec 4, 2015, at 22:24, Ivan Vučica <address@hidden> wrote:

1) and 2) will probably not happen for core project due to desire to build on odd platforms.
3) was proposed, I don't think anyone objected.
4) Dependency on libdispatch? *grumble*
No comments on the remainder. Even these items seem not completely necessary or compelling, and counter to the desire to run on many platforms.

Regarding distant goals:
14) Does this mean you intend to support XC's spec file format and plugin system?
15) Opal, being a 2d painting engine, has no relation to the compositing system (Wayland) nor a 3d rendering/compositing system (EGL). Please don't do this without expanding this.
17) I approve of this: not as a 'clone', but as a 'user-friendly, comparable, compatible alternative'. I started work on Zcode a while ago, but since I want to have a nice build system based on XC3-{like,compatible} plugins and spec-files, it got stuck. In fact, it makes sense to work on the build system first, for which the Xcode3-and-before-era Xcode is just a frontend with an integrated editor. How interesting will your implementation of build graph nodes classes be?

I also noticed you mention Opal in relation to CF a few times. Why?

On Fri, Dec 4, 2015 at 1:04 PM 陈北宗 <address@hidden> wrote:
Dear List:

I just forked libobjc2, base and corebase so I can restart the refactor project again, now using OS X 10.11 as the refactoring standard. I would like to know how should I contribute back?

Project plan:

1) Building with clang 3.6+ mandatory, even for C-only projects. This is to allow...
2) … gnustep-make as well as use of autotools or cmake deprecated, replaced with __have_include() macro provided by clang. Also parallelisation that used to plague gnustep-make should work better now. For other projects, Xcode project files would be used instead.
3) GC in libobjc2 removed and ARC mandated, just like OS X 10.11 and iOS 5.
4) The base build order will be libobjc2 - libdispatch - gnustep-base-headers - gnustep-corebase - gnustep-base. The tangled look is from the fact that a few Base classes are moved to CoreBase for the sake of TFB.
5) libobjc2 will install blocks-related headers at correct locations as if installed from libBlocksRuntime, as well as creating a symlink for libBlocksRuntime, essentially replacing it entirely.
6) libobjc-opts removed - LLVM 3.4 and beyond not supported anyway, and LLVM 3.6+ mandated here.
7) NSZone, CFAllocator and part of NSObject moved to libobjc2 (allow TFB to be implemented in CoreBase)
8) Added TFB pairs for the sake of simplicity (should not break contract if used properly): NSZone vs CFAllocator, NSRunLoop vs CFRunLoop, NSCountedSet vs CFBag, NSIndexSet vs CFBitVector, and a few more.
9) I will figure out a way to put CFNetwork in, maybe as a separate library, and reimplement a few Base classes on top of that.
10) CommonCrypto API is used as an abstract layer above OpenSSL and GnuTLS, replacing the crypto bundle. It is built separately as libcommoncrypto-openssl and libcommoncrypto-gnutls dynamic libraries but only one can be linked at a time. Both libraries will be under a 3-clause BSD license, acting as a legal buffer between either OpenSSL license mix or LGPL from the crypto library, and LGPL or GPL of the framework proper.
11) dispatch-io will be used heavily across CF and Foundation - libdispatch now a hard dependency.
12) I will try to find some mach port analogue from within POSIX API. DO and XPC will depend on it.
13) A set of macros for creating new CF classes will be provided (for the sake of Opal)

Distant goals:

14) DVTFoundation and xcodebuild cloned.
15) Opal, written on top of Wayland and EGL, replaces gnustep-back.
16) GUI would be taking advantage of ARC and Opal.
17) StepCode, a Xcode clone, based on libclang.

Max.
_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev


reply via email to

[Prev in Thread] Current Thread [Next in Thread]