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
