Re: Forking on Github and feedback

[陈北宗]

I am going to request this form before I merge my code back.

> On Dec 5, 2015, at 07:24, Gregory Casamento <address@hidden> wrote:
> 
> Maxthon,
> 
> You never even requested a copyright assignment form! :)  I'm not sure
> what you mean by "my changes are rejected yet again."   If you had
> submitted some changes they would have been considered.
> 
> GC
> 
> On Fri, Dec 4, 2015 at 11:43 AM, 陈北宗 <address@hidden> wrote:
>> Also a little notification, I am bumping soname of libobjc2 in my fork
>> (“libobjc2-ng” version 2.0) to libobjc.so.6. Debian occupied libobjc.so.4
>> and libobjc.so.5 so I performed this preventive sonamp bump. Also since this
>> refactor affected almost all parts of Base and CoreBase all soname versions
>> and major versions will be bumped.
>> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> Gnustep-dev mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>> 
> 
> 
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/