[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should we split the project into two branches?
From: |
Richard Frith-Macdonald |
Subject: |
Re: Should we split the project into two branches? |
Date: |
Mon, 14 Feb 2022 20:45:05 +0000 |
> On 14 Feb 2022, at 17:39, Andreas Fink <afink@list.fink.org> wrote:
>
>
>
> Richard Frith-Macdonald wrote on 14.02.22 17:43:
>>
>>> On 14 Feb 2022, at 14:59, Max Chan <xcvista@me.com> wrote:
>>>
>>>
>>>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald
>>>> <richard@frithmacdonald.me.uk> wrote:
>>>>
>>>>
>>>>
>>>>> On 14 Feb 2022, at 11:43, Max Chan <xcvista@me.com> wrote:
>>>>>
>>>>> Dear List,
>>>>>
>>>>> There are over and over again arguments on moving on to LLVM/clang for
>>>>> latest language features versus maintaining compatibility with
>>>>> old/uncommon platforms and GCC,
>>>> Really this is simply not the case among GNUstep developers.
>>>> Those of us who actually use the stuff just work with whatever we
>>>> prefer/need, because GNUstep already works with both toolchains.
>>> The hard requirement of allowing building using GCC means we are restricted
>>> to language features equivalent of OS X 10.6.8 or iOS 4.3.5,
>> Please don't spread such nonsense on the mailing lists.
>>
>> The fact that we have a huge base of code that builds with both GCC and
>> clang (and a small part that only functions when built with clang) in no way
>> restricts us in the way we write new code.
>>
>> Having highly portable code is a strong point, but that doesn't mean that
>> *all* features are equally portable or that contributors are required to
>> write perfect portable code.
>>
>> It does the project a huge disservice to tell developers they 'have to use
>> an ancient version of the language'. Please don't do it.
>
> It does the project a huge reality check to tell developers they 'have to use
> an ancient version of the language *IF THEY WANT TO CONTRIBUTE TO GNUSTEP*'.
> That's says it all.
It's YOU saying it, not GNUstep.
As far as reality is concerned, there is incontrovertable evidence that your
statement is false, in the form of the sourcecode repository, which contains
both lots of support for making portable code (usable with both compilers) as
well as some code built only with clang.
Now, if what you wanted to say is that GNUstep has a very strong preference for
portable code (and hence contributions of non-portable code are likely to be
replaced at some point by portable versions), that would be fine and true.
If you wanted to say that GNUstep is *extremely* reluctant to break portability
of existing code, that would also be fine and true. it's also a non-issue in
practice: who wants to rewrite working code to make it less portable?
There's also a coding style ... if you lay your code out differently, it's
going to get reformatted.
None of this prevents contributions as you suggest, it just means some
contributions are conditionally compiled, and some more likely to be altered by
others to make them available to a wider audiance.
- Re: Should we split the project into two branches?, (continued)
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Gregory Casamento, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, H. Nikolaus Schaller, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, Richard Frith-Macdonald, 2022/02/15
- Re: Should we split the project into two branches?, Hugo Melder, 2022/02/14
- Re: Should we split the project into two branches?, Derek Fawcus, 2022/02/15
- Re: Should we split the project into two branches?, H. Nikolaus Schaller, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?,
Richard Frith-Macdonald <=
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Gregory Casamento, 2022/02/14
- Re: Should we split the project into two branches?, Riccardo Mottola, 2022/02/14
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Sergei Golovin, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, H. Nikolaus Schaller, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, Riccardo Mottola, 2022/02/16
- Re: Should we split the project into two branches?, Max Chan, 2022/02/16