Re: Debian12 repository.

[Riccardo Mottola]

Hi,

Andreas Fink wrote:

The question now is what naming to choose

gnustep2...?
gnustep-arc..?
gnustep-clang-... ?


to be consistent with our runtime specification, I would use "ng".
After all, it is not gnustep that changes, but its runtime.

gnustep-clang could also do, since it denotes a change.

I wonder if ever gcc runtime improves what could happen. It is unlikely, 
but possible. Thus I would not use a "feature".


Riccardo

Re: Debian12 repository.

[Richard Frith-Macdonald]

> On 24 Nov 2023, at 13:14, Andreas Fink  wrote:
> 
> see http://repo.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  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?

> the tool is not found in the path

That means your path is wrong ... but that's easy to fix.

> But then why have a config tool when it only does half of the work.

The problem is not that the tool is doing 'half the work',  it's that your 
headers etc are in the wrong place because you misunderstood what this means:

> After changing the layout to gnustep

If your layout is 'gnustep' the resources are supposed to be found in the 
standard gnustep layout locations found from the root path you have set.
By default the root path is /usr/GNUstep (though you can configure the root of 
the layout to be somewhere other than /usr/GNUstep)

Most headers installed in the 'gnustep' layout will be in 
/usr/GNUstep/Local/Library/Headers and make will find them automatically.

It sounds like you have configured for the 'gnustep' layout, but are expecting 
to find resources in the old layout.  If you did, that would be bad (the two 
different installations would be interfering with each other;  not often 
obvious with headers, but when you have different versions of libraries built 
for different runtimes that's a real problem), so hacking flags to point to a 
different installation is a dangerous thing to do.

If you want the 'fhs' (headers in /usr/include) layout then that's the way you 
should configure gnustep-make.

Re: Debian12 repository.

[Andreas Fink]

see http://repo.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  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  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 > >:
>> 
>> gnustep2 sounds logical as its a logical upgrade path from old non arc.
>> 
>> 
>> I have built it that way now on 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 >> > 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 >>> >:
 
 The question now is what naming to choose
 
 gnustep2...?
 gnustep-arc..?
 gnustep-clang-... ?
 
 
 
> On 24 Nov 2023, at 11:04, Riccardo Mottola  > 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.

Re: Debian12 repository.

[H. Nikolaus Schaller]

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 :
> 
> gnustep2 sounds logical as its a logical upgrade path from old non arc.
> 
> 
> I have built it that way now on 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  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 :
>>> 
>>> The question now is what naming to choose
>>> 
>>> gnustep2...?
>>> gnustep-arc..?
>>> gnustep-clang-... ?
>>> 
>>> 
>>> 
 On 24 Nov 2023, at 11:04, Riccardo Mottola  
 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 

Re: Debian12 repository.

[Andreas Fink]

gnustep2 sounds logical as its a logical upgrade path from old non arc.


I have built it that way now on 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  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 :
>> 
>> The question now is what naming to choose
>> 
>> gnustep2...?
>> gnustep-arc..?
>> gnustep-clang-... ?
>> 
>> 
>> 
>>> On 24 Nov 2023, at 11:04, Riccardo Mottola  
>>> 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 m

Re: Debian12 repository.

[H. Nikolaus Schaller]

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 :
> 
> The question now is what naming to choose
> 
> gnustep2...?
> gnustep-arc..?
> gnustep-clang-... ?
> 
> 
> 
>> On 24 Nov 2023, at 11:04, Riccardo Mottola  
>> 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 exc

Re: Debian12 repository.

[Andreas Fink]

The question now is what naming to choose

gnustep2...?
gnustep-arc..?
gnustep-clang-... ?



> On 24 Nov 2023, at 11:04, Riccardo Mottola  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

Re: Debian12 repository.

[Riccardo Mottola]

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

Re: Debian12 repository.

[H. Nikolaus Schaller]

Well, getting MRC right is just a matter of debugging... Maybe it could be 
possible to write an ObjC 2.0 -> 1.0 preprocessor doing the tedious job. Then 
you could even use gcc for ObjC 2.0.

But generally you are right. If majority thinks ObjC 2.0 is beneficial and 
clang is the way to go, it is so...

Since I rarely use Obj-C libraries written by others, I just wonder if there 
are so many which are useful? Since the standard-Libraries (Frameworks) cover 
almost everything one needs for daily life. Well, there are some: 
https://github.com/trending/objective-c 

> Am 20.11.2023 um 16:44 schrieb Andreas Fink :
> 
> 
> its not only about converting your code. There is a gazillion of libraries 
> which users use which had been developed by others. Converting everything 
> backwards is a drawback.
> 
> Think of if you try to convert the linux kernel back to K&R C. Its doable but 
> its a very bad idea.
> 
> My main app originally was in C. I moved to ObjectiveC due to its excellent 
> memory mansgement. Never the less I managed to forget a few release calls 
> eating up memory. ARC has severely simplified my life. Going back would mean 
> changing 500'000 lines of code. Errors will sure be created.
> 
> --
> Sent from Canary 
> 
> On Montag, Nov. 20, 2023 at 4:33 PM, H. Nikolaus Schaller  > wrote:
> 
> 
>> Am 20.11.2023 um 16:10 schrieb Andreas Fink : 
>> 
>> Without support for ARC, the vast majority of code written in the past 15 
>> years will not work (or eat memory without ever freeing it up). Apple's 
>> reference guide to Objective C 2.0 which introduces ARC is from 2008! 
> 
> Well, if you know the alloc/retain/release/copy rules it is just some 
> diligent work to convert ARC to MRC code. Has to be done once and believe me, 
> I have done it several times. Wasn't difficult. Then also/still runs on 
> macOS. 
> 
> But you are right, if ObjC 2.0 was introduced 15 years ago it is only us 
> "old-timers" who still know the MRC rules. Although Linux kernel programmers 
> should also be familiar with get/put calls for refcounting. And their devm 
> mimicks the ARP. 
> 
> BR, 
> Nikolaus

Re: Debian12 repository.

[Andreas Fink]

its not only about converting your code. There is a gazillion of libraries 
which users use which had been developed by others. Converting everything 
backwards is a drawback.

Think of if you try to convert the linux kernel back to K&R C. Its doable but 
its a very bad idea.

My main app originally was in C. I moved to ObjectiveC due to its excellent 
memory mansgement. Never the less I managed to forget a few release calls 
eating up memory. ARC has severely simplified my life. Going back would mean 
changing 500'000 lines of code. Errors will sure be created.

--
Sent from Canary (https://canarymail.io)

> On Montag, Nov. 20, 2023 at 4:33 PM, H. Nikolaus Schaller  (mailto:h...@goldelico.com)> wrote:
>
>
> > Am 20.11.2023 um 16:10 schrieb Andreas Fink :
> >
> > Without support for ARC, the vast majority of code written in the past 15 
> > years will not work (or eat memory without ever freeing it up). Apple's 
> > reference guide to Objective C 2.0 which introduces ARC is from 2008!
>
> Well, if you know the alloc/retain/release/copy rules it is just some 
> diligent work to convert ARC to MRC code. Has to be done once and believe me, 
> I have done it several times. Wasn't difficult. Then also/still runs on macOS.
>
> But you are right, if ObjC 2.0 was introduced 15 years ago it is only us 
> "old-timers" who still know the MRC rules. Although Linux kernel programmers 
> should also be familiar with get/put calls for refcounting. And their devm 
> mimicks the ARP.
>
> BR,
> Nikolaus

Re: Debian12 repository.

[H. Nikolaus Schaller]

> Am 20.11.2023 um 16:10 schrieb Andreas Fink :
> 
> Without support for ARC, the vast majority of code written in the past 15 
> years will not work (or eat memory without ever freeing it up). Apple's 
> reference guide to Objective C 2.0 which introduces ARC is from 2008!

Well, if you know the alloc/retain/release/copy rules it is just some diligent 
work to convert ARC to MRC code. Has to be done once and believe me, I have 
done it several times. Wasn't difficult. Then also/still runs on macOS.

But you are right, if ObjC 2.0 was introduced 15 years ago it is only us 
"old-timers" who still know the MRC rules. Although Linux kernel programmers 
should also be familiar with get/put calls for refcounting. And their devm 
mimicks the ARP.

BR,
Nikolaus

Re: Debian12 repository.

[Andreas Fink]

On 20 Nov 2023, at 15:39, Riccardo Mottola  wrote:
> 
> Hi,
> 
> Andreas Fink wrote:
>> As far as renaming goes, well the packages in debian are so far outdated and 
>> seem no longer maintained that we should try to get a newer version into 
>> debian at some point.  But im not sure on how that process works . It might 
>> fail due to non support of gcc and maybe some platforms (such as RiscV 
>> because even clang fails to install currently).
>> 
> 
> this is not correct. If you check the current debian unstable packages, they 
> are quite up-to-date.
> 
> https://packages.debian.org/search?keywords=gnustep&searchon=names&suite=unstable§ion=all
> 
> Gives us:
> 
> 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?

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.

So if its compiled with gcc with the old runtime, we are in dead water for the 
future. clang is the only way for modern Objective-C which I think is mandatory 
to attract any decent Objc-developers to even consider GNUStep. One of the key 
targets of GNUStep is to be feature compatible (where possible) with MaOS which 
makes it a prime candidate for porting apps from MacOS to Linux and other Unix 
platforms. Without support for ARC, the vast majority of code written in the 
past 15 years will not work (or eat memory without ever freeing it up). Apple's 
reference guide to Objective C 2.0 which introduces ARC is from 2008!

In my eyes, the best would be to have ARC versions in a repo which are built 
with clang and will end up in debian stable at some time.
or have two version. gnustep and gnustep-legacy (non ARC). But I think it would 
not be compatible somehow to have both installed.

We can not avoid that we have to do a transition to clang.

So lets stick our heads together and decide on how we can make this as smooth 
as possible.

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?

Re: Debian12 repository.

[Riccardo Mottola]

Hi,

Andreas Fink wrote:
As far as renaming goes, well the packages in debian are so far 
outdated and seem no longer maintained that we should try to get a 
newer version into debian at some point.  But im not sure on how that 
process works . It might fail due to non support of gcc and maybe some 
platforms (such as RiscV because even clang fails to install currently).




this is not correct. If you check the current debian unstable packages, 
they are quite up-to-date.


https://packages.debian.org/search?keywords=gnustep&searchon=names&suite=unstable§ion=all

Gives us:

base: 1.29
gui: 0.30
back: 0.30

Randomly checking some other apps shows they are op to release 
(ProjectCenter, gorm, GNUMail)


which is just current to releases. You can't compare to "stable" 
releases, since those go through the various release cycles.


Thus it is quite important, in my opinion, that separately provided 
packages which use a different runtime, compiler or layout setup to be 
incompatible with debiansso that the user doesn't end with mix-matching 
applications. It would be quite cofusing.
Except a global renaming of all packages, I don't have a known way ho 
how to do that.


Just my 2 cents.

Riccardo