see http://repo.gnustep <http://gnustep/>.ch/
I am currently fighting with /usr/GNUstep/System/Tools/gnustep-config while compiling my own libraries After changing the layout to gnustep the tool is not found in the path. a symlink to /usr/bin/gnustep-config fixes this (or expanding the path) However gnustep-config --objc-flags does not include a -I/usr/include/GNUStep so <Foundation/Foundation.h> is not found It's not strictly necessary for pure objc code but for gnustep-base code it is. There is however no --base-flags but only --base-libs. I could simply add -I /usr/include/GNUStep to my Makefiles. But then why have a config tool when it only does half of the work. Suggestions? > On 24 Nov 2023, at 13:39, H. Nikolaus Schaller <h...@goldelico.com> wrote: > > Great! > > a) what is the entry for /etc/apt/sources.list? > > The I can test a little > > b) a next logical step would be to add meta-packages for > > - gap-minimal > depending on gnustep2 package + subpackages for each GAP > application > - gap full (some more less essential packages) > depending on gap-minimal > - gsde > depdendent on gap-minimal and some X11 setup and other libs and > apps (e.g. window manager) > > Then it becomes really user-friendly to install a full GNUstep desktop... > > BR, > Nikolaus > > >> Am 24.11.2023 um 13:11 schrieb Andreas Fink <af...@list.fink.org >> <mailto:af...@list.fink.org>>: >> >> gnustep2 sounds logical as its a logical upgrade path from old non arc. >> >> >> I have built it that way now on repo.gnustep.ch <http://repo.gnustep.ch/> >> >> debian12 on intel and arm64 >> >> armhf (raspberry pi), ubuntu22 (intel, arm64) will follow >> >> i also have built a metapackage named "gnustep2" if you install this, you >> basically get base, gui, back, corebase, libobjc2, libdispatch, libiconv >> >> >>> On 24 Nov 2023, at 12:42, H. Nikolaus Schaller <h...@goldelico.com >>> <mailto:h...@goldelico.com>> wrote: >>> >>> It seems as if API incompatiblities in libraries are usually denoted by a >>> numerical suffix. >>> >>> E.g. libfi6, libffi7, libffi8 >>> But there is also libjpeg62-turbo. >>> >>> Here are some hints. >>> https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_package_file_names >>> >>> So although it is clear that it must differ in "package" name, I would say >>> it is a little arbitrary. But is a decision carved in stone for quite some >>> time. >>> >>> Personally I would vote for gnustep2 (alluding to libobjc2). >>> >>>> Am 24.11.2023 um 11:23 schrieb Andreas Fink <af...@list.fink.org >>>> <mailto:af...@list.fink.org>>: >>>> >>>> The question now is what naming to choose >>>> >>>> gnustep2...? >>>> gnustep-arc..? >>>> gnustep-clang-... ? >>>> >>>> >>>> >>>>> On 24 Nov 2023, at 11:04, Riccardo Mottola <riccardo.mott...@libero.it >>>>> <mailto:riccardo.mott...@libero.it>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> let me try to explain a little the compatibility issue. I am not debating >>>>> if GCC is better or worse, but you want to provide an repository (would >>>>> be "overlay" in gentoo terms) to Debian or Ubuntu, which provides >>>>> differently configured packages. Runtime (in short, let's say ARC here) >>>>> is the major difference, but it could also be layout, root directory, etc. >>>>> The issue is that debian and ubuntu already provide GS packages which are >>>>> configured differently from "yours" and you cannot control how Debian >>>>> names its packages, only "your". >>>>> >>>>> I would configure these package e.g. with --with-layout=gnustep --prefix=/ >>>>> >>>>> This compatibility will remain even if in the future things will change. >>>>> GCC my acquire ARC and libobcj2, it will still be an issue for other >>>>> things. Debian might switch to clang, but you still have a different >>>>> layout... >>>>> >>>>> Also the amount of packages offered by you might differ. I suppose they >>>>> easily can be "more" because you could provide anything GNUstep has, but >>>>> you might choose not. >>>>> >>>>> You cannot control how debian names their packages right now you can't >>>>> just call them legacy. >>>>> >>>>> Andreas Fink wrote: >>>>>> >>>>>>> base: 1.29 >>>>>>> gui: 0.30 >>>>>>> back: 0.30 >>>>>>> >>>>>>> Randomly checking some other apps shows they are op to release >>>>>>> (ProjectCenter, gorm, GNUMail) >>>>>> Does that version support ARC? >>>>> >>>>> It is irrelevant, those versions are current versions, that is what I >>>>> wanted to show. It depends on how they are compiled and they are compiled >>>>> with gcc, so without ARC. >>>>> For all users which are not developers, they will not care, they install >>>>> an application and it works. Most applications we have do not require ARC. >>>>> Those who notice are mostly developers now. Or in the future more apps >>>>> will be ARC-only, who nows. >>>>> >>>>>> As far as I remember gcc simply doesn't support it. Sticking around with >>>>>> gcc is a dead end. It looks to me like gcc never will ever support >>>>>> objective-2.0 fully. >>>>>> I never even considered the debian packages because ARC does not work >>>>>> with them and thats kind of mandatory now. >>>>> >>>>> While it is up for debate if GCC is a dead-end or not, it was not my >>>>> point. You need to consider debian packages, since they exist and are in >>>>> the official repositories. >>>>> While the libobjc2 runtime is "runtime" compatible with non-ARC code, it >>>>> is (no longer is?) binary compatible with it. So you have to cover e.g. >>>>> these two scenarios: >>>>> >>>>> Debian repo first: >>>>> 1) debian user installs some GNUstep user packages. E.g GWorkspace, >>>>> Terminal and PRICE. They pull in of course gnustep core libraries >>>>> 2) user wants to develop, installs ProjectCenter&GORM, dev packages, ecc >>>>> 3) user needs ARC, adds your repository >>>>> 4) user needs to replace existing packages with "your" packages. All of >>>>> them! Even if they have the same "version" number they need to be >>>>> mutually exclusive >>>>> 5) if a package is not provided by your package it needs to be removed. >>>>> E.g. you provide core, ProjectCenter and GWorkspace, but not Terminal and >>>>> PRICE. They need to me deleted because of unavailable dependency >>>>> >>>>> GS repo first (happy flow) >>>>> 1) debian user does not have any GS app or library installed >>>>> 2) User adds your GS repos, install what it needs, e.g. Core, >>>>> ProjectCenter and GWorkspace >>>>> 3) user attempts to add Terminal and PRICE which you do not provide, he >>>>> needs to fail to install the debian provided versions >>>>> >>>>>> What incompatibilities do we end up having if we use the new runtime 2.0 >>>>>> only? >>>>>> non ARC written code can still be executed. What other clashes will we >>>>>> face? >>>>> >>>>> To my knowledge and experience, in most code I am involved in there is no >>>>> end-user difference. I have two workstations, they run the "same" >>>>> software (all gnustep core tool & apps, all GAP apps + PRICE and some >>>>> custom apps none of which needs objc2) one on linux with GCC and one with >>>>> FreeBSD and clang/libobjc2 and they all compile and run the same. >>>>> Provided you are on a fully supported arch/OS combination, no issues. >>>>> >>>>> Sure there are differences when you debug, compile and things. There may >>>>> be bugs, e.g. do that on NetBSD and with libobjc2 your exceptions won't >>>>> work. >>>>> >>>>> I wanted to stress the "package tree" incompatibility issue, where mixing >>>>> is impossible for many reasons, not just compiler and runtime. >>>>> >>>>> Riccardo >>>> >>>> >>>> >>> >> >
