I would like to add another plus for dropping GCC: if we want any hope for Swift interworking, we have to use clang as the compiler.
Apple have no plan to provide any GUI support on Linux version of Swift. If we have Swift interworking, even though we may have to drop our own libobjc, Foundation and CoreFoundation in favor of Apple’s release, the GNUStep GUI package can provide the replacement AppKit that Apple’s Swift release lacked. 顺颂商祺 陈北宗 Max Chan, from SushiBits Projects Tel. +86 186-2165-8748 https://github.com/SushiBits > On Nov 24, 2019, at 15:21, Johannes Brakensiek <[email protected]> > wrote: > > > On 24 Nov 2019, at 2:24, Yavor Doganov wrote: > > Ivan Vučica wrote: > > On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov <[email protected]> wrote: > > The answer is simple: because there's a lot to lose and nothing to > gain. > > This is unfortunately wrong. There is a lot to gain. > > Right or wrong depends on the point of view, which ultimtately boils > down to one's values and beliefs. What is gain for some may be loss > for others. It appears we have different values, hence the > discrepancy. > > Developers who want to start using Debian-built GNUstep libraries > can start using tons and tons of features that GCC and GCC runtime > do not support. > > Developers who want to start using these new (not so new -- 10 years > old!) features have the option to build the environment they need on > top of Debian (if that is their distro of choice) or switch to another > distro that provides prebuilt packages. > > But that is the wrong answer. > > You, developers, tend to forget that free software is for users. > Developers are users too in a broad sense but they are a very small > part of the whole mass of people using a particular piece of software. > If these fancy features existed for 10 years, why they have not > inclined developers to write more free software that is relying on > them? Surely that's not because Debian stopped them? Or because the > GNUstep project is stopping them? > > My task as a free software contributor (with the extremely limited > skills I have) is to help achieve the goals of the Free Software > Movement. Providing "tons and tons of features" to developers who > don't care at all about free software (at least the majority of them) > and who won't write a single line of code for the cause I'm aligned to > doesn't strike me as the "right" thing to do. > > I don't mind helping them as a side effect of helping free software. > In this case, however, it is all about them. > > - ARC is one. > - Blocks is another. > - @123 syntax for NSNumber (and similar stuff for arrays and dicts and > more) is another. > - Improved @property support is yet another. > > This is like offering rocket fuel to someone who has a car with a > diesel engine. None of the packages in Debian is using these > features, which is why I said there's nothing to win. There's a queue > of software packages we intend to package in Debian but neither of > them depends on these things -- except probably the Rik theme and > NEXTSPACE (which are not suitable for packaging for other reasons). > > Right now I'm working on a new upstream release of a package which > uses NSNotificationCener-addObserverForName:object:queue:usingBlock:. > This is a method which is declared and supposed to be supported even > with GCC, I just don't know the (GCC) syntax I'm supposed to use so > I'm experimenting with GCC nested functions as replacement. If that > fails, I guess I'll solve it somehow, using a different approach. > That's the first case I face ever -- I've seen methods using blocks in > upstream code before but they were no-op anyway as there was no > GNUstep implementation. On the contrary, there are tons of > block-unrelated things which are not implemented, especially in GUI. > > The biggest hurdle with porting apps IMVHO is missing functionality > and dependency on Core* stuff and other libraries with no free > implementation. The switch to Clang is not going to solve these > problems. The only thing it solves is making the life of developers > of properiatary software easy. That is not my goal. > > But I'd say that Debian's packaging of GNUstep is very important and > even if the core doesn't start depending on these features, they > should be made available. > > I don't know why Debian is important, but they cannot be made > available as an option. It would mean duplicate packages with > different names -- the release team will not allow it and the > ftpmasters will not allow it. > > You probably weren't around when we (GNUstep people in Debian) had to > scrap and fight to prevent it from being removed. GNUstep in Debian > back then was undermaintained and violated the FHS, it was also full > of bugs (that is, obvious bugs such as frequent failures to build from > source) and blatant bugs solely due to packaging. Hubert wrote a tool > to FHS-ify most of the packages, we fixed most bugs and we had a > helping hand from the Debian GCC maintainers who said it would be very > worthwile to keep GNUstep in Debian, at least as a testing ground for > GCC. > > And that's what it's been, more or less; GNUstep had a rapid decline > in the user base some years ago and it appears it is not going to > recover. All the Clangs in the world are not going to help you with > that. But in your quest for popularity you may lose some of the solid > foundations that are still keeping this project afloat. > > What's lost is builds on some architectures. Can't those architectures > keep using GCC-targeting libraries or be actively disabled? > > No. Packages which no longer build for a particular architecture must > be removed manually by the ftpmasters, after a request is filed. If > the architecture is official (meaning it is officially supported in > the stable version of the distro about to be released) it must be > decided by the release team. > > In case it still isn't clear -- I repeat, there is no middle ground to > support both compilers/runtimes. > > Hey Yavor, > > would it be possible to somehow ship a clang runtime on Debian or isn’t it? > If it is how could it be achieved? > > It seems to me you are making this a „the egg or the chicken“ problem, which > it isn’t. If you don’t provide new tools for developers they are not going to > build new software for their users. It’s this way around not the other and > it’s no dilemma at all. (You know the good old enemy yelling „developers, > developers, developers“. He was right.) > > For me this cause is indeed a decision whether you are most comfortable with > the state in which GNUstep currently is or if you would be more comfortable > when it would develop to a further state, maybe one where most ObjC currently > is. If you want it to develop the decision should be simple. > > Just one last thing to add: Cocoa/Mac software development is not the same as > proprietary software development. There is a lot of good quality free > software for Cocoa which would be of great use if it could be ported to a > free desktop environment. To just mention a few: > > https://github.com/64characters/Telephone > https://github.com/subethaedit/SubEthaEdit > http://colloquy.info/ > https://github.com/rburgst/time-tracker-mac > I think many here know a lot more. > > Just my two cents. Thank you for your work and endorsement for free software > and Debian packaging! > Johannes
