libtool
[Top][All Lists]
Advanced

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

Re: tips for checking changes to library version numbers?


From: Michel Briand
Subject: Re: tips for checking changes to library version numbers?
Date: Thu, 4 Dec 2008 05:19:29 +0100

Brian Gough <address@hidden> - Thu, 27 Nov 2008 19:34:45 +0000

>Hello,
>
>Does anyone have any good ways to check that updates to -version-info
>numbers accurately reflect the actual changes in the API of a library
>when making a new release?
>
>Currently I do this by (1) comparing 'nm' output against the old
>library to find any added/deleted functions (2) manually inspecting a
>diff of the header files (3) looking at the accumulated NEWS/Changelog
>entries for possible changes in semantics.
>
>I am open to suggestions for reducing human error... thanks.
>

Hello,

another check I can imagine is about the version of your library.

Lets put the version in some file under source control (CVS, SVN,
whatever). Remove it from the build system (Makefile, config.h) or,
simply, ignore the version generated by AC_INIT (PACKAGE_VERSION).

And lets define in configure.ac that this file (VERSION), if modified,
should trigger some tasks: for example propagate the library version's
into its source code. But you can image other tasks...

I've built a scheme like this to use the trigger to update the
internal_version.c that define a version string and a get version
method :

-- in configure.ac ---
# We have a script (vtempl) that uses a system command (sed): we need
# to be sure to call the good sed binary whatever the system is. So we 
# ask autotools to check for us the good sed command (please look into
# vtempl.in for details) (and we ensure that it'll be executable):
AC_CONFIG_FILES([vtempl],[chmod +x vtempl])

--- in vtempl.in ---
#!/bin/sh
#
# Transform a template containing @component@ and @VERSION@
#

# autoconf will search for a decent sed program and 
# replace this pattern with its full path:
SED='@SED@'

if [ $# -ne 2 ] ; then
        echo "Two arguments required: component and version." >&2
        exit 1
fi

_component=$1
_version=$2

# Beware: keywords here must not conflit with autotools
# variables!!! That's for I put an _

"$SED" -e "s/@_component@/$_component/g" \
       -e "s/@_version@/$_version/g"

exit $?

--- in version.c.in ---
/**
 * FreeX3D
 *
 * Template for embedded versioning.
 *
 */

const char address@hidden@_version = "@_version@";

const char address@hidden@_get_version()
{
        return @address@hidden;
}

--- in Makefile.am ---
# where the versions are defined
_EV=$(top_srcdir)/versions/LIBFREEX3D
_EV2=$(top_srcdir)/versions/LIBFREEX3D_LTVERSION
export
# tool to update internal_version.c
templ=$(top_srcdir)/versions/template/version.c.in
component=libFreeX3D
LIBFREEX3D_VERSION=`cat $$_EV`
LIBFREEX3D_LTVERSION=`cat $$_EV2`
# Generate the version source file
internal_version.c: $(_EV)
        $(top_srcdir)/vtempl $(component) \
        $(LIBFREEX3D_VERSION) < $(templ) > $@
# And add it to the list of files to clean
CLEANFILES=internal_version.c
# Add it to the SOURCES for automatic dependency tracking
libFreeX3D_la_SOURCES += internal_version.c
libFreeX3D_la_LDFLAGS = -version-info $(LIBFREEX3D_LTVERSION)

And that's all. Automatic version embedded in your C source files ;).

Cheers,
Michel









reply via email to

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