activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Pocock <dan...@readytechnology.co.uk>
Subject Re: ActiveMQ-CPP libtool issues
Date Tue, 04 Dec 2007 08:58:18 GMT



Point taken - I realise this stuff is time consuming.  On the other 
hand, we only have to address it once, and then come up with a set of 
rules for the project.

The link I provided suggests some rules for using -version-info:

http://www.gnu.org/software/libtool/manual.html#Versioning

There are some choices to be made, maybe they've been taken already, so 
I'll summarise the proposals:

a) Unique interface number for every ActiveMQ-CPP release, e.g:

2.1.1 = 2:0:0
2.1.2 = 3:0:0
2.2.0 = 4:0:0
3.0.0 = 5:0:0
...

Under this scheme, an application built with 2.1.1 will refuse to link 
with 2.1.2 at runtime.  This is clearly very paranoid - but it will 
work.  In a system like Debian or Red Hat, this is not very practical - 
if a user has two applications, one of which was built with 2.1.1 and 
the other was built with 2.1.2, then the user will need to have both 
versions of the library.  In practice, both applications may work with 
2.1.2.

b) More complicated:
- major releases (2.x, 3.x) break binary compatibility
- minor releases (2.1.x, 2.2.x) may add new function prototypes, but 
without breaking binary compatibility
- patches (2.1.1, 2.1.2 etc) make no change to the interface

(-version-info current:revision:age)
2.1.1 = 2:0:0
2.1.2 = 2:1:0    ; notice the revision number is incremented
2.1.3 = 2:2:0    ; notice the revision number is incremented again
2.2.0 = 3:0:1    ; a new function is added, so binary compatibility with 
2:x:x is preserved - therefore, the `age' is incremented
2.2.1 = 3:1:1
2.3.1 = 4:0:2    ; age is incremented again, to ensure compatibility 
with 3:x:x and 2:x:x (current - age = 4 - 2 = 2, therefore 2:x:x is 
compatible)
3.0.0 = 5:0:0    ; function prototype arg list changed - binary 
compatibility broken: age is reset to 0, because there is no compatibility
 with 4:x:x or earlier

Using the second approach requires more discipline - whenever a release 
occurs, someone needs to decide if this is this a patch, a minor release 
or a major release.  However, the results are much better - for example, 
applications built with 2:1:0 will happily link at runtime with 2:2:0 or 
3:0:1.  Therefore, the user can install 2.3.1 on their system, delete 
2.2.1, and continue using their applications without re-compiling.

Regards,

Daniel



-- 


-----------------------------------------------------------------------
Ready Technology Limited
Incorporated in England and Wales, 4940731
Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD
-----------------------------------------------------------------------


Mime
View raw message