Re: [PATCH] Framework shlib versioning

[Nicola Pero]

> 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.