libtool
[Top][All Lists]
Advanced

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

Re: libtool versioning


From: Jason Curl
Subject: Re: libtool versioning
Date: Thu, 06 May 2010 19:57:05 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

Hi Ralf & Bob,

On 03/05/2010 19:58, Ralf Wildenhues wrote:
Hello,

* Matěj  Týč wrote on Mon, May 03, 2010 at 05:45:26PM CEST:
If I have understood correctly, the whole LTversion stuff has only one
purpose - to inform users what have they installed.
Wrong.  It provides a fairly portable abstraction of different
versioning schemes implemented in different operating systems/libc's.
By definition, libtool cannot do better than what the native system
provides.  In cases where the native system provides even less than what
the libtool versioning is able to express, such as w32, it has to resort
to library renaming to get even a chance of a kind of "versioning".
I have a similar problem as the author in developing libraries that can be compiled on Unix as well as Windows/Cygwin. I've implemented a solution to my problem, where I have a resource that specifies a version as well as a filename.

See, there are the following details that are typical for a Windows Resource (rsrc.rc.in):
VALUE "OriginalFilename", "@MYLIBFILENAME@"
VALUE "FileVersion", "@MYLIBVERSION@"
VALUE "ProductVersion", "@MYPROGVERSION@"

where MYLIBFILENAME is the "guessed" filename that libtool will generate (I can't get this directly from libtool, or a script, or conf files - instead I get the .la filename and this is not correct).

MYLIBVERSION is the version of the file. I don't use the MS version scheme, but use one similar to unix that works just as well: Major.Minor.Revision.Build. This can be different for each library in my package.
 - Major is the major version as used in Unix
 - Minor is the minor version as used in Unix
 - Revision is the revision as used in Unix
- Build is my own value, usually obtained from SVN, or incremented and stored somewhere on each configure invocation And it works for installers too. They can update my library when they need to (assuming I haven't inserted bugs and I've reviewed my code thoroughly enough for ABI breakages).

MYPROGVERSION is then the version given in AC_INIT.

Unfortunately, to get MYLIBFILENAME and MYLIBVERSION (a.b.c) I needed to implement a new macro that effectively copies the content of what's in libtool, duplicating it. I would have /loved/ to somehow pull this information instead from libtool. And I only need this information for cygwin/windows. I'm even happy to let libtool add a version to the end, like "libmyprog-1.dll" and "libmyprog-2.dll" if I change the ABI. I consider this a very useful feature.

I know a lot of talk has been going on about automatic versioning, this could be used to cover the case for the "build" setting used in Windows Resources. If anyone would like, I can post a template I've set up that works for both CVS and SVN (sorry, no GIT, ClearCase, etc.)

Cheers,
Ralf


_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool






reply via email to

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