subject:"Re\: libtool versioning"

Re: libtool versioning

2010-05-06 Thread Peter Rosin


Den 2010-05-06 19:45 skrev Jason Curl:

On 04/05/2010 20:41, Peter Rosin wrote:

Den 2010-05-04 20:00 skrev Ralf Wildenhues:

Ah, ok. Yes, you're right. Feel free to commit a patch to
s/removed/& or changed/ in 6.

Sorry I came in late for the discussion. Is it correct to interpret
"removed" as an interface has been removed, or an interface has been
changed so as to cause a binary incompatibility, so that bumping the
major version is the result to indicate it is not 100% binary compatible
with the previous version, and therefore may break a program that is
already compiled against this library?


Hi Jason,

's/removed/& or changed/' could have been spelled out in full as
's/removed/removed or changed/' if that clarifies the situation for
you?

So, both removing an interface and changing an interface
cause a binary incompatibility, so both actions need a major
version bump and age=0 (i.e. not compatible with previous
versions).

Cheers,
Peter

--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?


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

Re: libtool versioning

2010-05-06 Thread Jason Curl


On 04/05/2010 20:41, Peter Rosin wrote:

Den 2010-05-04 20:00 skrev Ralf Wildenhues:

Errrm, is that really so? I tend to agree with Jef here...


I take it that your response is to my "... it will work" sentence, not
the paragraph below that.


Ah, indeed.

The algorithm *could* be interpreted such that e.g. the interface 
change
"int foo(void)" ->  "int foo(int)" is an interface addition of int 
foo(int)
and an interface remove of int foo(void), thus triggering both #5 
and #6.
But in that case "changed" need not be mentioned in #4 either. So, 
because

"changed" is mentioned in #4, it also needs to be explicitly mentioned
in #6.


Ah, ok.  Yes, you're right.  Feel free to commit a patch to
s/removed/&  or changed/  in 6.
Sorry I came in late for the discussion. Is it correct to interpret 
"removed" as an interface has been removed, or an interface has been 
changed so as to cause a binary incompatibility, so that bumping the 
major version is the result to indicate it is not 100% binary compatible 
with the previous version, and therefore may break a program that is 
already compiled against this library?


I've pushed the attached patch...

Cheers,
Peter

2010-05-05  Peter Rosin 

Clarify versioning algorithm documentation.
* doc/libtool.texi (Updating version info): Be explicit
about setting age to zero on interface change.
Reported by Jef Driesen 



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


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

Re: libtool versioning

2010-05-06 Thread Jason Curl


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

   




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

Re: libtool versioning

2010-05-05 Thread Peter Rosin


Den 2010-05-04 20:00 skrev Ralf Wildenhues:

Errrm, is that really so? I tend to agree with Jef here...


I take it that your response is to my "... it will work" sentence, not
the paragraph below that.


Ah, indeed.


The algorithm *could* be interpreted such that e.g. the interface change
"int foo(void)" ->  "int foo(int)" is an interface addition of int foo(int)
and an interface remove of int foo(void), thus triggering both #5 and #6.
But in that case "changed" need not be mentioned in #4 either. So, because
"changed" is mentioned in #4, it also needs to be explicitly mentioned
in #6.


Ah, ok.  Yes, you're right.  Feel free to commit a patch to
s/removed/&  or changed/  in 6.


I've pushed the attached patch...

Cheers,
Peter

2010-05-05  Peter Rosin  

Clarify versioning algorithm documentation.
* doc/libtool.texi (Updating version info): Be explicit
about setting age to zero on interface change.
Reported by Jef Driesen 


--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?
diff --git a/doc/libtool.texi b/doc/libtool.texi
index f73f5a7..bbc22f4 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2927,8 +2927,8 @@ If any interfaces have been added since the last public 
release, then
 increment @var{age}.
 
 @item
-If any interfaces have been removed since the last public release, then
-set @var{age} to 0.
+If any interfaces have been removed or changed since the last public
+release, then set @var{age} to 0.
 @end enumerate
 
 @stro...@emph{never}} try to set the interface numbers so that they
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool versioning

2010-05-04 Thread Ralf Wildenhues

* Peter Rosin wrote on Tue, May 04, 2010 at 10:05:37AM CEST:
> Den 2010-05-03 22:03 skrev Ralf Wildenhues:
[...]
> >#  3. If the library source code has changed at all since the last 
> >update,
> ># then increment revision (`c:r:a' becomes `c:r+1:a').
> >#  4. If any interfaces have been added, removed, or changed since the 
> >last
> ># update, increment current, and set revision to 0.
> >#  5. If any interfaces have been added since the last public release, 
> >then
> ># increment age.
> >#  6. If any interfaces have been removed since the last public release,
> ># then set age to 0.
> 
> Shouldn't step #6 included "changed" as well as "removed"? If you
> change the interface (for example modifying function parameters),
> backwards compatibility is broken too. But only "removed" is listed
> here.
> >>>
> >>>Well, it is listed in step 4 already.
> >>
> >>Sure, but if interfaces have been changed, but not removed, the
> >>algorithm stops at step #4,
> >
> >Read the algorithm without any implicit stops in mind, and it will work.
> >
> >Anyway, your point is good that this is hard to understand, and we've
> >addressed that in git master.
> 
> Errrm, is that really so? I tend to agree with Jef here...

I take it that your response is to my "... it will work" sentence, not
the paragraph below that.

> The algorithm *could* be interpreted such that e.g. the interface change
> "int foo(void)" -> "int foo(int)" is an interface addition of int foo(int)
> and an interface remove of int foo(void), thus triggering both #5 and #6.
> But in that case "changed" need not be mentioned in #4 either. So, because
> "changed" is mentioned in #4, it also needs to be explicitly mentioned
> in #6.

Ah, ok.  Yes, you're right.  Feel free to commit a patch to
s/removed/& or changed/  in 6.

Thanks for perservering!
Ralf


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

Re: libtool versioning

2010-05-04 Thread Peter Rosin


Den 2010-05-03 22:03 skrev Ralf Wildenhues:

* Jef Driesen wrote on Mon, May 03, 2010 at 08:24:09PM CEST:

Yes, I have read the libtool manual, but it doesn't contain much
info about the resulting filename. Most of the info is about the
c:r:a scheme for input, not the output.


Yes, because the output file name is a per-system detail that you should
not have to care about.


#  1. Start with version information of `0:0:0' for each libtool library.
#  2. Update the version information only immediately before a public
# release of your software. More frequent updates are unnecessary, and
# only guarantee that the current interface number gets larger faster.
#  3. If the library source code has changed at all since the last update,
# then increment revision (`c:r:a' becomes `c:r+1:a').
#  4. If any interfaces have been added, removed, or changed since the last
# update, increment current, and set revision to 0.
#  5. If any interfaces have been added since the last public release, then
# increment age.
#  6. If any interfaces have been removed since the last public release,
# then set age to 0.


Shouldn't step #6 included "changed" as well as "removed"? If you
change the interface (for example modifying function parameters),
backwards compatibility is broken too. But only "removed" is listed
here.


Well, it is listed in step 4 already.


Sure, but if interfaces have been changed, but not removed, the
algorithm stops at step #4,


Read the algorithm without any implicit stops in mind, and it will work.

Anyway, your point is good that this is hard to understand, and we've
addressed that in git master.


Errrm, is that really so? I tend to agree with Jef here...

The algorithm *could* be interpreted such that e.g. the interface change
"int foo(void)" -> "int foo(int)" is an interface addition of int foo(int)
and an interface remove of int foo(void), thus triggering both #5 and #6.
But in that case "changed" need not be mentioned in #4 either. So, because
"changed" is mentioned in #4, it also needs to be explicitly mentioned
in #6.

Or what am I missing?

Cheers,
Peter

--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?


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

Re: libtool versioning

2010-05-04 Thread Tor Lillqvist

>>> 

I am not a native English speaker, but I find the use of "may use" a
bit confusing in the added text. I would suggest changing some
instances of "may use" to "are able to use" and some to "might be
using". (It should be clear in what way I mean, I hope...) Hopefully
that will make the text even clearer.

--tml


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

Re: libtool versioning

2010-05-03 Thread Michel Briand


Jef Driesen  - Mon, 03 May 2010 20:24:09 +0200

>On 03/05/10 20:00, Ralf Wildenhues wrote:
>> Hello Jef,
>>
>> * Jef Driesen wrote on Mon, May 03, 2010 at 09:08:14AM CEST:
>>> On 02/05/10 03:33, Bob Friesenhahn wrote:
 On Sun, 2 May 2010, Jef Driesen wrote:

>> The git master version of Libtool is hopefully a bit easier to
>> understand, it has an alternate description added, which is similar to
>> yours:
>> 
>
>I find this a more intuitive description. I'm sure others will 
>appreciate it too!
>

Wow !

Nice new explanation. Congratulations Ralf ! That's a big job.



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

Re: libtool versioning

2010-05-03 Thread Ralf Wildenhues

* Jef Driesen wrote on Mon, May 03, 2010 at 08:24:09PM CEST:
> Yes, I have read the libtool manual, but it doesn't contain much
> info about the resulting filename. Most of the info is about the
> c:r:a scheme for input, not the output.

Yes, because the output file name is a per-system detail that you should
not have to care about.

> >>>#  1. Start with version information of `0:0:0' for each libtool library.
> >>>#  2. Update the version information only immediately before a public
> >>># release of your software. More frequent updates are unnecessary, and
> >>># only guarantee that the current interface number gets larger faster.
> >>>#  3. If the library source code has changed at all since the last update,
> >>># then increment revision (`c:r:a' becomes `c:r+1:a').
> >>>#  4. If any interfaces have been added, removed, or changed since the last
> >>># update, increment current, and set revision to 0.
> >>>#  5. If any interfaces have been added since the last public release, then
> >>># increment age.
> >>>#  6. If any interfaces have been removed since the last public release,
> >>># then set age to 0.
> >>
> >>Shouldn't step #6 included "changed" as well as "removed"? If you
> >>change the interface (for example modifying function parameters),
> >>backwards compatibility is broken too. But only "removed" is listed
> >>here.
> >
> >Well, it is listed in step 4 already.
> 
> Sure, but if interfaces have been changed, but not removed, the
> algorithm stops at step #4,

Read the algorithm without any implicit stops in mind, and it will work.

Anyway, your point is good that this is hard to understand, and we've
addressed that in git master.

Cheers,
Ralf


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

Re: libtool versioning

2010-05-03 Thread Jef Driesen

On 03/05/10 20:00, Ralf Wildenhues wrote:

Hello Jef,

* Jef Driesen wrote on Mon, May 03, 2010 at 09:08:14AM CEST:

On 02/05/10 03:33, Bob Friesenhahn wrote:

On Sun, 2 May 2010, Jef Driesen wrote:

I'm trying to understand the libtool current:revision:age versioning scheme.
I think I understand how it works, but I noticed that filename of the shared
library seems to get different numbers (current-age.age.revision). Is that
expected?

The filename generation is dependent on the OS. It is usually best
not to pay any attention to the filenames at all unless you are
switching from some other existing numbering scheme and need to avoid
a collision. I keep these notes in my configure script (taken from
various libtool related documentation) so that I remember how things
work:

The reason why I found the filename confusing, is because in the
article I was looking at, they make it look like the libtool version
c:r:a ends up in the filename as "libfoo.so.c.r.a".

http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_once_using_autotools

I'm adding John in Cc:, he should be able to say more about this.

I have seen this a couple of other places as well.

Like, the GNU Libtool manual? Have you looked there?

Yes, I have read the libtool manual, but it doesn't contain much info
about the resulting filename. Most of the info is about the c:r:a scheme
for input, not the output.

As a newbe to the
libtool versionning scheme, it took me a while to figure out what
was really going on. Very confusing.

# Here are a set of rules to help you update your library version
# information:
#
# 1. Start with version information of `0:0:0' for each libtool library.
# 2. Update the version information only immediately before a public
# release of your software. More frequent updates are unnecessary, and
# only guarantee that the current interface number gets larger faster.
# 3. If the library source code has changed at all since the last update,
# then increment revision (`c:r:a' becomes `c:r+1:a').
# 4. If any interfaces have been added, removed, or changed since the last
# update, increment current, and set revision to 0.
# 5. If any interfaces have been added since the last public release, then
# increment age.
# 6. If any interfaces have been removed since the last public release,
# then set age to 0.

Shouldn't step #6 included "changed" as well as "removed"? If you
change the interface (for example modifying function parameters),
backwards compatibility is broken too. But only "removed" is listed
here.

Well, it is listed in step 4 already.

Sure, but if interfaces have been changed, but not removed, the
algorithm stops at step #4, and you get:

c+1:0:a

But if an interface has been removed, you have to apply #6 and get:

c+1:0:O

But in both situations backwards compatibility has been broken. So I
would think you have to apply step #6 in both cases.

Personally, I think the last three steps are easier to understand
when written as if cases, rather than steps:

1. Interface unchanged: C:R+1:A
2. Interface changed in a backwards compatible way: C+1:0:A+1
3. Interface changed and backwards compatibility is broken: C+1:0:0

The git master version of Libtool is hopefully a bit easier to
understand, it has an alternate description added, which is similar to
yours:

I find this a more intuitive description. I'm sure others will
appreciate it too!

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

Re: libtool versioning

2010-05-03 Thread Ralf Wildenhues

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

Cheers,
Ralf


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

Re: libtool versioning

2010-05-03 Thread Ralf Wildenhues

Hello Jef,

* Jef Driesen wrote on Mon, May 03, 2010 at 09:08:14AM CEST:
> On 02/05/10 03:33, Bob Friesenhahn wrote:
> >On Sun, 2 May 2010, Jef Driesen wrote:
> >
> >>I'm trying to understand the libtool current:revision:age versioning scheme.
> >>I think I understand how it works, but I noticed that filename of the shared
> >>library seems to get different numbers (current-age.age.revision). Is that
> >>expected?
> >
> >The filename generation is dependent on the OS.  It is usually best
> >not to pay any attention to the filenames at all unless you are
> >switching from some other existing numbering scheme and need to avoid
> >a collision.  I keep these notes in my configure script (taken from
> >various libtool related documentation) so that I remember how things
> >work:
> 
> The reason why I found the filename confusing, is because in the
> article I was looking at, they make it look like the libtool version
> c:r:a ends up in the filename as "libfoo.so.c.r.a".
> 
> http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_once_using_autotools

I'm adding John in Cc:, he should be able to say more about this.

> I have seen this a couple of other places as well.

Like, the GNU Libtool manual?  Have you looked there?

> As a newbe to the
> libtool versionning scheme, it took me a while to figure out what
> was really going on. Very confusing.
> 
> ># Here are a set of rules to help you update your library version
> ># information:
> >#
> >#  1. Start with version information of `0:0:0' for each libtool library.
> >#  2. Update the version information only immediately before a public
> ># release of your software. More frequent updates are unnecessary, and
> ># only guarantee that the current interface number gets larger faster.
> >#  3. If the library source code has changed at all since the last update,
> ># then increment revision (`c:r:a' becomes `c:r+1:a').
> >#  4. If any interfaces have been added, removed, or changed since the last
> ># update, increment current, and set revision to 0.
> >#  5. If any interfaces have been added since the last public release, then
> ># increment age.
> >#  6. If any interfaces have been removed since the last public release,
> ># then set age to 0.
> 
> Shouldn't step #6 included "changed" as well as "removed"? If you
> change the interface (for example modifying function parameters),
> backwards compatibility is broken too. But only "removed" is listed
> here.

Well, it is listed in step 4 already.

> Personally, I think the last three steps are easier to understand
> when written as if cases, rather than steps:
> 
> 1. Interface unchanged: C:R+1:A
> 2. Interface changed in a backwards compatible way: C+1:0:A+1
> 3. Interface changed and backwards compatibility is broken: C+1:0:0

The git master version of Libtool is hopefully a bit easier to
understand, it has an alternate description added, which is similar to
yours:


Cheers,
Ralf


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

Re: libtool versioning

2010-05-03 Thread Gary V. Vaughan

On 3 May 2010, at 23:09, Bob Friesenhahn wrote:
> On Mon, 3 May 2010, Matěj  Týč wrote:
>>> 
>> 
>> If I have understood correctly, the whole LTversion stuff has only one
>> purpose - to inform users what have they installed.
> 
> More specifically, it provides libtool with the information needed to produce 
> a suitably numbered library to satisfy a purpose.  As you say, libtool does 
> not provide control over which versions of libraries are consumed in a link 
> since only the current version in the linker search path, or the version 
> indicated by a .la file, gets used.

Almost certainly (assuming you don't have a very customized installation), even 
though you might have several old versions of a library to support the 
applications you linked against it, you still have only one set of header files 
at any given time, and they will describe the API of the newest version of the 
library they pertain to.  And that is the library you want the compiler driver 
to find when it builds new software on your system, and the one you want the 
runtime linker to find next year when you've installed a newer version of that 
library, and replaced the headers with the ones that describe the API of that 
version.

Libtool is trying to make this happen automatically on as many systems as it 
can, as long as the people who develop and/or package libraries for your system 
maintain the libtool version numbers according to the rules in the Libtool 
manual.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

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

Re: libtool versioning

2010-05-03 Thread Bob Friesenhahn


On Mon, 3 May 2010, Matěj  Týč wrote:




If I have understood correctly, the whole LTversion stuff has only one
purpose - to inform users what have they installed.


More specifically, it provides libtool with the information needed to 
produce a suitably numbered library to satisfy a purpose.  As you say, 
libtool does not provide control over which versions of libraries are 
consumed in a link since only the current version in the linker search 
path, or the version indicated by a .la file, gets used.


I don't think that this makes libtool useless by any means.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool versioning

2010-05-03 Thread Bob Friesenhahn


On Mon, 3 May 2010, Jef Driesen wrote:

#  6. If any interfaces have been removed since the last public release,
# then set age to 0.


Shouldn't step #6 included "changed" as well as "removed"? If you change the 
interface (for example modifying function parameters), backwards 
compatibility is broken too. But only "removed" is listed here.


Yes, "changed" is the same as "removed".  Square blocks don't fit in 
round holes.  Increment current and set age to 0.  Changing an 
interface is a big deal.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


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

Re: libtool versioning

2010-05-03 Thread Matěj Týč

>> I'm trying to understand the libtool current:revision:age versioning
>> scheme. I think I understand how it works, but I noticed that filename of
>> the shared library seems to get different numbers
>> (current-age.age.revision). Is that expected?
>
> The filename generation is dependent on the OS.  It is usually best not to
> pay any attention to the filenames at all unless you are switching from some
> other existing numbering scheme and need to avoid a collision.  I keep these
> notes in my configure script (taken from various libtool related
> documentation) so that I remember how things work:
>

If I have understood correctly, the whole LTversion stuff has only one
purpose - to inform users what have they installed.
You can't tell to libtool like "link only with libfoo of LTversion >=
5" or something like that, neither you can "read" the version using an
AC macro or libtool itself.
So the whole LTversion concept looks quite attractive, but,
unfortunatelly, not so useful.
If this is correct, I could try some doc patch describing the actual
importance of LTversion stuff.
Regards,
Matěj


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

Re: libtool versioning

2010-05-03 Thread Jef Driesen

On 02/05/10 03:33, Bob Friesenhahn wrote:

On Sun, 2 May 2010, Jef Driesen wrote:

The reason why I found the filename confusing, is because in the article
I was looking at, they make it look like the libtool version c:r:a ends
up in the filename as "libfoo.so.c.r.a".

http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_once_using_autotools

I have seen this a couple of other places as well. As a newbe to the
libtool versionning scheme, it took me a while to figure out what was
really going on. Very confusing.

Shouldn't step #6 included "changed" as well as "removed"? If you change
the interface (for example modifying function parameters), backwards
compatibility is broken too. But only "removed" is listed here.

Personally, I think the last three steps are easier to understand when
written as if cases, rather than steps:

1. Interface unchanged: C:R+1:A
2. Interface changed in a backwards compatible way: C+1:0:A+1
3. Interface changed and backwards compatibility is broken: C+1:0:0

If find this more intuitive because it's more similar with the typical
major.minor.micro scheme, where minor and micro are equivalent with age
and revision. Only the major number is really different from the libtool
current number, because that last one is increased with every interface
change.

One of the reasons why I would like to know the filename is that I'm also
building a Windows DLL (it's a cross platform library) where I would like to
include a version resource. And one of the fields in a Windows version
resource is the "OriginalFilename". It seems that dlls get filename
libfoo-x.dll, where x is the number current-age. Is that correct?

It is true that Windows does not support useful versioning and is not
able to select among DLLs based on an interface version. It seems
that your analysis is correct.

Thanks for the info.

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

Re: libtool versioning

2010-05-01 Thread Bob Friesenhahn


On Sun, 2 May 2010, Jef Driesen wrote:

I'm trying to understand the libtool current:revision:age versioning scheme. 
I think I understand how it works, but I noticed that filename of the shared 
library seems to get different numbers (current-age.age.revision). Is that 
expected?


The filename generation is dependent on the OS.  It is usually best 
not to pay any attention to the filenames at all unless you are 
switching from some other existing numbering scheme and need to avoid 
a collision.  I keep these notes in my configure script (taken from 
various libtool related documentation) so that I remember how things 
work:


# Libtool library revision control info
# See the libtool documentation under the heading "Libtool's versioning
# system" in order to understand the meaning of these fields
#
# current
#  The most recent interface number that this library implements.
# revision
#  The implementation number of the current interface.
# age
#  The difference between the newest and oldest interfaces that
#  this library implements. In other words, the library implements
#  all the interface numbers in the range from number current -
#  age to current.
#
# Here are a set of rules to help you update your library version
# information:
#
#  1. Start with version information of `0:0:0' for each libtool library.
#  2. Update the version information only immediately before a public
# release of your software. More frequent updates are unnecessary, and
# only guarantee that the current interface number gets larger faster.
#  3. If the library source code has changed at all since the last update,
# then increment revision (`c:r:a' becomes `c:r+1:a').
#  4. If any interfaces have been added, removed, or changed since the last
# update, increment current, and set revision to 0.
#  5. If any interfaces have been added since the last public release, then
# increment age.
#  6. If any interfaces have been removed since the last public release,
# then set age to 0.

One of the reasons why I would like to know the filename is that I'm also 
building a Windows DLL (it's a cross platform library) where I would like to 
include a version resource. And one of the fields in a Windows version 
resource is the "OriginalFilename". It seems that dlls get filename 
libfoo-x.dll, where x is the number current-age. Is that correct?


It is true that Windows does not support useful versioning and is not 
able to select among DLLs based on an interface version.  It seems 
that your analysis is correct.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


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

47 matches

Mail list logo