I'm sure that there are a lot of things that we do wrong in the
configure scripts, but so far I can't find anyone who really know what
the right thing to do with the autotools is. It would be nice if there
was a "Best Practices" document for the autotools that we could refer to.
I personally have no time to really investigate this right now, probably
won't till sometime next year.
What I would do if you'd like to get something changed is:
1. Write a Jira issue documenting that there is a problem.
2. Investigate the problem and the correct solution
3. Describe in simple terms (not autoconf language) what the problem is
and how to fix it. Keep in mind that people how work on this project do
so in their spare time and have extremely limited resources to read
large bodies of documentation.
4. If applicable. Submit a patch that corrects the problem.
If the solution involves steps that the maintainer needs to follow when
making a release then I'd recommend editing the Wiki for Creating
Distributions: http://activemq.apache.org/cms/creating-distributions.html
This will ensure that when a release is made the maintainer has
something to help them get it done correctly.
Regards
Tim.
Daniel Pocock wrote:
I've just been looking at the way libtool is used by ActiveMQ-CPP,
in anticipation of creating some Debian packages.
The parameters to -version-info are defined like this:
current = 2 = current interface version
revision = 1 = the revision of the library (binary compatibility is
preserved across revisions)
age = 2 = the difference between the newest and oldest interface that
this library implements
The numbers above (2:1:2) are the values used when building ActiveMQ-CPP.
It appears
that this is just the ActiveMQ-CPP version number - the libtool
version-info has a
completely different meaning.
The second and third parameters may not be correct. Why?
- Is 2.0 and 2.1 binary compatible? If no, then `current' must be
incremented, just
changing revision is not sufficient.
- Setting `age = 2' implies that 2.x, 1.x and 0.x are all binary
compatible. In other
words, we are asserting that no function prototypes or struct
definitions have changed
between between the current version and version (current - age = 2 - 2 =
0 = 0.x).
- For instance, if 1.x and 2.x are NOT binary compatible, age must be set
to 0.
http://www.gnu.org/software/libtool/manual.html#Versioning
It also appears that both -version-info and -release are used. This may not
be necessary. Having a unique `release' for each release that breaks
binary compatibility is a good idea. However, does 2.x.2 break
binary compatibility with 2.x.1? If not, then release should just
be 2.x instead of 2.x.2.
It would be useful if you could have a look at the Debian Library
Packaging Guide, particularly the section about choosing the
package name and numbering conventions:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id250154
Here is the libtool command issued on my system when using make:
/bin/sh ../../libtool --tag=CXX --mode=link g++ -ansi -pedantic -W -Wall
-fPIC
-fstrict-aliasing -Wstrict-aliasing=2 -Wno-long-long -g -O2 -version-info
2:1:2
-release 2.1.2 -o libactivemq-cpp.la -rpath /usr/lib
activemq/core/libactivem
q_cpp_la-ActiveMQConsumer.lo ...........
