[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Framework shlib versioning
From: |
Nicola Pero |
Subject: |
Re: [PATCH] Framework shlib versioning |
Date: |
Wed, 14 Jan 2004 19:16:37 +0000 (GMT) |
> By the way, there's a question in the makefile as to the effect of
> xxx_DEPLOY_WITH_CURRENT_VERSION. It is there so that you can install a
> version of a framework that is not to become the default. In our case, that
> means that the Current link should not be changed while installing, and that
> the version being installed should not have the .so symlink updated to point
> to it. It should probably be a Master variable, not an Instance variable,
> because of this.
Thanks for the explanation. Interesting! It probably needs more work
then - your point is very good, if we could implement so that it works as
you say and still it is an instance variable, that would be the best
thing. :-)
> > I'm now very tempted to do the following changes -
> >
> > introduce a PACKAGE_VERSION variable which should be used instead of
> > the current VERSION variable for versions of packages (if
> > PACKAGE_VERSION is empty, the value is set from VERSION, so it's
> > backwards compatible)
>
> That's good.
Ok - I've done this change.
> > introduce a xxx_VERSION variable both in libraries and frameworks (if
> > xxx_VERSION is empty, the version is set from xxx_CURRENT_VERSION_NAME
> > (for frameworks only, for backwards compatibility) if that is not empty,
> > else, it is taken from VERSION (backwards compatibility again), else
> > it's set to 1.0.0 (please note that this would be done for frameworks
> > too, instead of 'A'))
> >
> > replace any usage of CURRENT_VERSION_NAME with VERSION in frameworks
>
> I don't like this, for the simple reason that it means a framework has two
> different version strings that may not be the same. The version name has a
> distinct link to the structure of the framework.
I'm confused - I think I agree with what you say, so I might/must have
explained myself badly :-)
Let me describe everything again from scratch so we're sure there is no
misunderstanding and once we agree, I can make the changes.
I think that a framework should have a single version string, so that you
know that libMyFramework.so.1.4.5 is using the resources in
Versions/1.4.5/Resources (or, if you prefer letters or a general version
string, libMyFramework.so.C is using Versions/C/Resources).
Otherwise it'd be a bit difficult (impossible ?) to match resources with
the shared libraries.
For this reason, I'd like to unify VERSION and CURRENT_VERSION_NAME which
are currently separated.
I think that was precisely the main point in your patch, and I totally
agree with you it's something we want to do - thanks for finding the
problem! :-)
My solution would be a bit more aggressive though, as I'd want to get rid
of xxx_CURRENT_VERSION_NAME completely, and deprecate it in favour of the
single variable xxx_VERSION, which would control both the string used in
the shared library (and given to the linker) and the string used as
version name in Versions/.
Since we can't have all GNUmakefiles updated immediately, old GNUmakefiles
defining xxx_CURRENT_VERSION_NAME would still work: gnustep-make would
simply do something like
VERSION = $(strip $($(GNUSTEP_INSTANCE)_VERSION))
ifeq ($(VERSION),)
VERSION = $(strip $($(GNUSTEP_INSTANCE)_CURRENT_VERSION_NAME))
ifeq ($(VERSION),)
VERSION = 1.0.0
endif
endif
I prefer VERSION to CURRENT_VERSION_NAME because
1. it's shorter and simpler and easier to remember and understand :-)
2. the same variable can be used for libraries (and potentially for other
future stuff having versioning) as well
Let me state again that xxx_VERSION would be the only and single way of
defining a framework's version (xxx_CURRENT_VERSION_NAME would still work,
but it's just for backwards compatibility).
Let me know if this sounds a good plan.
> In addition, a framework version must not ever have an empty version name.
> It's needed for finding that version's resources.
Yes/sure, a framework version will never be empty - as there is a default
value which kicks in if the framework version is empty (after stripping).
> > Any comments before I do these changes ? Particularly on why the
> > default framework version should or should not be 'A' versus '1.0.0'.
> > To me '1.0.0' looks a much better choice, but I'm open to do differently
> > if given a good reason :-)
>
> It's not particularly important. I believe that the decision at NeXT to do
> this seems pretty arbitrary. Maybe it holds some meaning in that it drives
> home the notion that you shouldn't change the version name too lightly, and
> perhaps that it's not related to the version name/number of your package.
>
> By the way, NeXT used names instead of numbers for all of their dynamic
> libraries, not just frameworks. For example, libsys_s.dylib on OPENSTEP is a
> symbolic link to libsys_s.A.dylib, and libperl.dylib is a symlink to
> libperl.5.dylib. The 5 was used for perl because it was perl 5, the fifth
> binary-incompatible version of the lib, and because it matched with the
> version on the other platforms Perl worked on. Obviously, libsys_s never
> became binary-incompatible. :)
Ok - I think switching to 1.0.0 is OK then.
Thanks for your time, I really appreciate your help. It's not easy to get
frameworks right without some helpful suggestions :-)
Thanks for your comments and for taking time to discuss this issue with
me.
- [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/10
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/12
- Re: [PATCH] Framework shlib versioning, Dennis Leeuw, 2004/01/12
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/12
- Re: [PATCH] Framework shlib versioning,
Nicola Pero <=
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/15
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/16
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/17
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/17
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/19
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/19
- Re: [PATCH] Framework shlib versioning, Nicola Pero, 2004/01/27
- Re: [PATCH] Framework shlib versioning, Jeff Teunissen, 2004/01/29