> On 25 Nov 2019, at 14:37, Yavor Doganov <ya...@gnu.org> wrote: > > Gregory Casamento wrote: >> On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov <ya...@gnu.org> wrote: >>> The answer is simple: because there's a lot to lose and nothing to >>> gain. > >> This is patently incorrect. The gain is time and compatibility with >> the latest code base. I laid out the advantages and disadvantages >> of this in my previous posting. > > There are no advantages for the current GNUstep packages in Debian > which is the main point I was trying to make. I don't dispute the > fact that dropping support for GCC will simplify things a lot for > you. At certain cost, of course, which you consider negligible. > >> * More Applications, more applications means more end users (sort of >> chicken and egg thing) > > That's purely hypothetical to the extent of being mere speculation. > GNUstep supports Clang and David's runtime for quite some time now, > why there are no more applications? Why existing GNUstep applications > have not been updated to take advantage of the new features?
I can tell you exactly why. When I tried out GNUstep for the first time to port my OS X apps to Debian, I simply did "apt-get install gnustep" and wanted to compile my code and nothing really worked. Then it took me several weeks to figure out how to get a working toolchain with libobjc2 and ARC support which my code required. And I am not a newbie. I write code on MacOS since 1994 and Linux since like 1992. The major roadblocks where: a) the tools which come with Debian where totally useless as it did not support modern Objc2 features which my ported code was using already. And it took a while to even figure that out. b) the build process is not well documented. You find all kinds of build info out there in the net out of which most are totally outdated and don't work anymore. (this has become a bit better since). c) there where some bugs, especially in the linking part which where totally throwing you off the rails and where giving very puzzling information. d) if you don't pay attention, the old runtime libobjc which comes with gcc gets into your way. And the package is named libobjc4. So go figure that libobjc2 is actually newer... I can assure you that people who are used to MacOS X and Xcode , 99% of it will run away. They will simply claim GnuStep is not a mature project. If you read through my readme https://github.com/andreasfink/ulib/blob/master/doc/README-Debian9-stretch.txt <https://github.com/andreasfink/ulib/blob/master/doc/README-Debian9-stretch.txt> you will see how many things can go wrong. Part of the problem was that Debian 9 was packaging clang 3.8 which is quire old these days and was lacking some stuff as well. Recent Debian 10 however fixed this and adding clang from the llvm repository to get a newer version is kind of not a big issue. These days you need clang8 or newer if you don't want to run into some nasty bugs and use a prebuilt package. The linker was one of the biggest problem. Easy to fix but very difficult to figure. I also tried other options beforehand. Namely Cocotron. The problem with that was that its built for crosscompiling from a Mac. Recent upgrades from Xcode basically broke that and I think the folks who work on that are mainly focused to get it run well on Windows and don't care so much about Linux. Also there's not much happening with Cocotron these days. Hence I dropped using it and use GNUStep for all my ObjC code under Linux these days. And for me its performing very well, once I had working packages. >> What's to lose: >> * Possibly a political issue with the FSF, but there are other projects >> which depend on languages not implemented by GCC. > > I'm not aware of any GNU package written in a compiled language that > cannot be built with GCC. I'm not aware of any other GNU package written in ObjC (or even any other compiled language besides C or C++). > I don't know what you mean by "political issue" but such a drastic > change should be discussed with the GNU Project of which GNUstep is > still part of. It is wrong to decide it with a vote that doesn't even > specify simple things like who is eligible to vote and based on what > majority the decision is going to be taken. As a GNU maintainer you > should know these things. > >> * Support for older platforms which ONLY support gcc. > > RISC-V is the newest GNU/Linux architecture and it's not yet supported > by Clang. Wrong https://riscv.org/2019/10/llvm-clang-risc-v-now-supports-lto-michael-larabel-phoronix/ <https://riscv.org/2019/10/llvm-clang-risc-v-now-supports-lto-michael-larabel-phoronix/> > >> So, I apologize if I don't agree with the "nothing to gain" opinion. > > You are free to disagree. But as it often happens with real life, the > loss may become obvious only post factum... You could be left only > with the "gain" which may not look like a big gain then. It could > even look more like you have shot yourself in the foot. I think it boils down to the question if we want to keep GNUStep as a clone of NextStep (before Apple took over) or if we want it to be useable for porting software from OSX to Unix. For me the answer is clear. As far as all the other platforms go which might not be supported by clang and are supported by gcc: Can we get a bit more concrete and list all Debian supported platforms who have prebuilt GNUStep packages today and who do not have clang support? And I mean platforms who will have long term support (not like i386 or Tile or something which is about to be dropped). (https://en.wikipedia.org/wiki/Debian#Architecture_ports <https://en.wikipedia.org/wiki/Debian#Architecture_ports>) As of the Stretch release, the official ports are:[157] <https://en.wikipedia.org/wiki/Debian#cite_note-packages_base-files-157> amd64: x86-64 <https://en.wikipedia.org/wiki/X86-64> architecture with 64-bit userland and supporting 32-bit software arm64: ARMv8-A architecture[158] <https://en.wikipedia.org/wiki/Debian#cite_note-two-ports-158> armel: Little-endian <https://en.wikipedia.org/wiki/Endianness> ARM architecture <https://en.wikipedia.org/wiki/ARM_architecture> (ARMv4T instruction set)[159] <https://en.wikipedia.org/wiki/Debian#cite_note-159> on various embedded systems (embedded application binary interface <https://en.wikipedia.org/wiki/Application_binary_interface>(EABI)) armhf: ARM hard-float architecture (ARMv7 instruction set) requiring hardware with a floating-point unit <https://en.wikipedia.org/wiki/Floating-point_unit> i386: IA-32 <https://en.wikipedia.org/wiki/IA-32> architecture with 32-bit userland, compatible with x86-64 machines[153] <https://en.wikipedia.org/wiki/Debian#cite_note-hreqs2-153> mips: Big-endian MIPS architecture <https://en.wikipedia.org/wiki/MIPS_architecture> mips64el: Little-endian 64 bit MIPS mipsel: Little-endian MIPS ppc64el: Little-endian PowerPC <https://en.wikipedia.org/wiki/PowerPC> architecture supporting POWER7 <https://en.wikipedia.org/wiki/POWER7>+ and POWER8 <https://en.wikipedia.org/wiki/POWER8> CPUs[158] <https://en.wikipedia.org/wiki/Debian#cite_note-two-ports-158> s390x: z/Architecture with 64-bit userland, intended to replace s390[160] <https://en.wikipedia.org/wiki/Debian#cite_note-160> Lets see what clang-10 supports under Debian10 # llc-10 --version LLVM (http://llvm.org/): LLVM version 10.0.0 Optimized build. Default target: x86_64-pc-linux-gnu Host CPU: znver1 Registered Targets: aarch64 - AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm - ARM arm64 - ARM64 (little endian) arm64_32 - ARM64 (little endian ILP32) armeb - ARM (big endian) avr - Atmel AVR Microcontroller bpf - BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) hexagon - Hexagon lanai - Lanai mips - MIPS (32-bit big endian) mips64 - MIPS (64-bit big endian) mips64el - MIPS (64-bit little endian) mipsel - MIPS (32-bit little endian) msp430 - MSP430 [experimental] nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX riscv32 - 32-bit RISC-V riscv64 - 64-bit RISC-V sparc - Sparc sparcel - Sparc LE sparcv9 - Sparc V9 systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) wasm32 - WebAssembly 32-bit wasm64 - WebAssembly 64-bit x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore - XCore So the real question is: Are we ok to drop support for s390x in exchange of support of Objc2.0 support and much cleaner code in libobjc2 ? Personally I don't know anyone who even has a s390x so I can't even tell if it makes any sense to have Gnustep on such a platform.
