Hi
I dont understand this problem about ABI and binary compatibility, so
please excuse me if this looks stupid :\
The problem comes from ivars that would not be always at the same
offset, doesn't it ? But these ivars are supposed to be private, dont
they ? So the code that uses these ivars is always released along with
the class interface. I can not find any official 'public' ivars. Do i
miss something ?
And if the ivars need to be used from outside the library/bundle (for
internal use), why not access them thru accessors? Obj-C accessors or
even simple C function that would read or write the value, or return a
pointer, or even a member pointer (offset)...
My 2 cts.
-- Regards
- Xavier
Gregory Casamento a écrit :
The last collective release was only two months ago.
As far as the ABI is concerned that is certainly an issue. The last
time we discussed it we came up with two solutions:
* Pad the ivar-structures in the classes out to give space to grow
so that it pushes off any ABI compatibility issues as long as
possible. This is why in some APIs, including Cocoa, you see
things like "reserved..." or "private..." variables. These are
there to give room to grow. The disadvantage is that the classes
would then take up more memory as a result.
* Move the ivar-structures out of the classes and replace them with
a void pointer to the actual structure. This has the advantage
that we will never be able to break ABI compatibilty since the
sizes of the structs in the classes will not change... but it also
has the disadvantage of adding a layer of complexity to getting
and setting variables as well as potentially causing unpredictable
issues due to unforseen incompatibilities such as cases where the
wrong data is written into a data structure causing some sort of
corruption when using the wrong version of a library.
I, personally, think we should implement the first option. It's the
method most APIs follow and it is the method that is the most
predictable. It would take some effort to do this, but it's minimal
since it's really just padding the structures with a given amount of
space.
GC
P.S. Sorry for the double mail, Stefan, I meant to reply to all, but
curse gmail it defaults to reply. :)
On Thu, Mar 5, 2009 at 8:35 AM, Stefan Bidigaray <stefanb...@gmail.com
<mailto:stefanb...@gmail.com>> wrote:
I thought that's what GNUstep-startup was supposed to be used for?
I've personally never used it, but the way I understand it all you
need to do is "./InstallGNUstep", right?
In my opinion, it's more important to have up-to-date packages than
anything else, however, one needs to keep in mind that most
distributions do not follow the latest and greatest. I, for
example, use Debian Testing + GNOME most of the time and I know I
will never have the latest release of packages, people need to
realize this. Tell you the truth, except for when I create GNUstep
packages and build scripts for Slackware, I never compile a single
piece of software. Why is it different with GNUstep? Why do people
WANT to compile in the first place?
If I can rant a little... GNUstep also gets way behind when it comes
to releases. How long has it been since the last collective
release? Why isn't GNUstep releasing more stable releases? It
seems everytime a new release of the core packages are out I need to
recompile everything because it breaks ABI. Rarely do I see a x.x.1
release.
I've been wanting to bring that up for a while, figured this was as
a good a time as any.
Stefan
On Wed, Mar 4, 2009 at 10:33 PM, Gregory Casamento
<greg.casame...@gmail.com <mailto:greg.casame...@gmail.com>> wrote:
Hey guys... it seems to me that the build guides for building
from source that we have are out of date. Could we move some
of this stuff to the wiki so that it can be more readily maintained?
Also, it seems like a lot of users are having issues using
GNUstep because the packages are so old on many systems.
Currently Hubert is working on
What brought this up is that I was trying to help someone get
gnustep installed since the packages are out of date.
Anyone have any thoughts?
GC
--
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org <mailto:Gnustep-dev@gnu.org>
http://lists.gnu.org/mailman/listinfo/gnustep-dev
--
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev