gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Framework shlib versioning


From: Dennis Leeuw
Subject: Re: [PATCH] Framework shlib versioning
Date: Mon, 12 Jan 2004 14:50:28 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3

Nicola Pero wrote:
Some time ago, we had a discussion about frameworks and framework mobility.
One of the things that I brought up was that frameworks are not versioned.

Well, it turns out that frameworks _are_ versioned, but the version used is
that of the $(VERSION) make variable, otherwise only used for building
distributions.

Attached is a patch that makes the shlib version and soname filenames
contain a framework's version name. If a version name contains one or more
periods, it will be split as normal to form the soname filename.

Most of the patch is actually a target.make change that causes this change
to not be circumvented by the shared library build system for the cases
where the version filename and the soname filename are the same (like the
default case of "A").

Obviously, this can assist with libraries as well, because $(VERSION) is not
checked to ensure it has at least one period in it, and because libraries
with a single version element are valid.

This makes it possible to have multiple versions of a framework installed,
and they will still be found by the dynamic linker...which, I am pretty sure
we will all agree is a Good Thing(tm).


Thanks.  Looks interesting.  I'd definitely agree that using VERSION is
not a good idea :-) that's a 'global' variable, while we'd need a version
for each framework.

Your checks that VERSION_FILE and SONAME_FILE are different are also very
good; I've committed those to CVS (after changing the style, from 'test
xxx != yyy && AAA' into 'if [ xxx != yyy ]; then AAA; fi' which is the
form normally used inside gnustep-make).  Thanks for your contribution!

=

<thinking>

I wonder why xxx_CURRENT_VERSION_NAME is used in frameworks, and not
simply xxx_VERSION (easier to remember, and the same name could be used
for libraries).

Btw why do frameworks have 'A' as default version and not '1.0.0' ?  'A',
'B', 'C', ... is very limited as a range of versions ... you can only have
26, and there is no difference between major/minor/subminor releases.

Just a wilde guess... assume someone releases a framework without the version set. And an automated installer wants to update the no-version-set framework with one that has the version set.

Simple logic can determine that a version of just A, B, C is probably not a real version, but a mistake. While a return value of 1.0.0 might be a real version and if the framework with version is 0.5.0 the framework is not updated.

Maybe not a real good example but I think you get the picture.

Dennis


=

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)

 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

=

Everything using VERSION in the old way should still work, but newly
written makefiles could then have

PACKAGE_VERSION to set the version of the package (used when building .tgz and such stuff)

xxx_VERSION to set the version of a library or a framework (works in the same way with both, so you don't have to learn a different API for each)

 VERSION could be used as a shorthand to force the same version number for
all libraries and frameworks being built in the same GNUmakefile

It looks like this would be a good setup, simple to remember, consistent
and easy.


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 :-)


Anyway, thanks Jeff for your help and contribution, much appreciated! :-)



_______________________________________________
Gnustep-dev mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnustep-dev






reply via email to

[Prev in Thread] Current Thread [Next in Thread]