Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0.0, 1.1.0, 1.2.0
-
None
-
None
-
CentOS 5.3, MacOS X
Description
Up to this point, the autotools configuration for C did not manage the shared library version information.
Also, the project version was hard-cored at "1".
I've fixed this by doing the following:
1. created a top-level "version.sh" file which pull the project version from build.xml or calculates the current, revision and age for libtool
2. used the m4_esyscmd() macro where needed to insert the correct version information without a dependency on version.sh
3. added the -version-info and -release LDFLAGS to libavro
The top-level version.sh script has nice comments to make it easy for C developers to know what to do when there are changes to libavro.
Tested the fix by running
$ autoreconf -f -i
$ mkdir _build
$ cd _build
$ ../configure && make distcheck
$ gunzip < avro-c-*.tar.gz | tar -xvf -
$ cd avro-c*
$ ./configure --prefix=/tmp/testavro && make install && find /tmp/testavro
/tmp/testavro
/tmp/testavro/include
/tmp/testavro/include/avro.h
/tmp/testavro/lib
/tmp/testavro/lib/libavro.so
/tmp/testavro/lib/libavro.la
/tmp/testavro/lib/libavro-1.2.0-dev.so.0
/tmp/testavro/lib/libavro.a
/tmp/testavro/lib/libavro-1.2.0-dev.so.0.0.1
which shows that the top-level project version and the public API version information for libavro are being processed correctly now
