discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Should we split the project into two branches?


From: Max Chan
Subject: Re: Should we split the project into two branches?
Date: Tue, 15 Feb 2022 08:14:10 -0500


> On Feb 15, 2022, at 7:10 AM, Andreas Fink <afink@list.fink.org> wrote:
> 
> Question:
> is it time to start working on libobjc3 with Swift support and support
> for all platforms we want to support?
> (if libobj3 is an upgrade of libobjc2 or a rewrite being put aside for now).

Or should we just work backwards, building on top of Apple’s code releases for 
Swift?

> Apple will run away in a decade with Swift only. So if our goal is to
> keep OS X compatibility, then we have to think long term on how we think
> we want to continue
> 
> I would thus suggest to make a list of pro & cons of the current
> situation. Especially I want to know
> 
> a) which platforms are supported today with gcc and the old runtime
> b) which platforms are supported today with gcc and libobjc2
> c) which platforms are supported today with clang and the old runtime
> d) which platforms are supported today with clang and libobjc2
> e) which platforms do we want to support in the future.

For the future I only see Windows-amd64, Linux-amd64, Windows-aarch64, 
Linux-aarch64 and Linux-riscv64 as popular. All of them 64-bit systems. 
Windows-amd64 recently gained a Linux compatibility layer (WSL) so that target 
can have a lower priority.

> I personally have no problem to drop MIPS as I never used it. Others
> might have a different view.

MIPS is dead-end anyway. All companies previously used MIPS ave announced 
migration to ARM or RISC-V, including MIPS the company.

> Having gnustep-base in embedded systems without GUI might be useful.
> But do they need all the new features we plan to add? Might it be better
> to move that part to a "classic" release for historic systems?

For embedded systems, we probably should stick to the new architecture, just 
chopping off features that does not make sense for devices of that scale. Apple 
managed to strip macOS into iOS into watchOS into Touch Bar into HomePod then 
into T2, we can do the similar thing. However embedded systems does bring back 
a 32-bit architecture for us as a kind-of popular target: Linux-armv7.

> I would like to see support for RISC-V as I see a lot of future growth
> there.

RISC-V can wait now as it is just taking off and still need time to grow before 
the installation base is large enough.

> I think its time to do a reality check to figure out commonly on where
> we do want to see GNUStep in the future. What should it accomplish and
> what are the pro's and cons of each.
> Only if such facts are on the table, one can decide on a roadmap.
> 
> 
> Max Chan wrote on 15.02.22 00:28:
>> 
>>> On Feb 14, 2022, at 6:06 PM, Riccardo Mottola <riccardo.mottola@libero.it> 
>>> wrote:
>>> 
>>> I continue to think that a restriction into core libraries is
>>> acceptable, if it leaves the freedom for your "app code" (or... other
>>> code you need of course).
>>> 
>> The problem is that our core libraries are dreadfully outdated. It is on par 
>> with Mac OS X 10.6.8, which is a decade old now. This whole Next branch idea 
>> is to remove the restriction on the new branch so people interested in or 
>> need new features can chase the latest features, a big one being Swift 
>> interoperability, and leave the tasks of restoring compatibility to the main 
>> branch as an “afterthought.”
>> 
>>> PS: indeed I think there is no servce in continuing to denigrate our own
>>> project, including menacing splits or fork. It was my first thought too,
>>> but I hope it can be avoided, by a single solution with options or
>>> configurations.
>>> 
>> IMO it can eventually be done especially after we bring in Swift support, as 
>> that gives us two parallel build systems, one of which has a hard dependency 
>> on the new features. For people needs legacy support they can still use 
>> gnustep-make and the makefiles; while people using new features skip 
>> gnustep-make entirely and use Swift Package Manager instead. SPM hard 
>> depends on Swift, which is one of the new language features I consider worth 
>> breaking compatibility for.
> 
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

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