AC_SET_RELEASEINFO_VERSIONINFO_AND_DEFINES [(VERSION)] -*- sh -*-
default $1 = $VERSION
check the $VERSION number and cut the two last digit-sequences off
which will form a -version-info in a @VERSIONINFO@ ac_subst while
the rest is going to the -release name in a @RELEASEINFO@ ac_subst.
you should keep these two seperate - the release-name may contain
alpha-characters and can be modified later with extra release-hints
e.g. RELEASEINFO="$RELEASINFO-debug" for a debug version of your lib.
example: a VERSION="2.4.18" will be transformed into
-release 2 -version-info 4:18
and for a linux-target this will tell libtool to install the lib as
libmy.so libmy.la libmy.a libmy-2.so.4 libmy-2.so.4.0.18
and executables will get link-resolve-infos for libmy-2.so.4 - therefore
the patch-level is ignored during ldso linking, and ldso will use the
one with the highest patchlevel. Using just "-release $(VERSION)"
during libtool-linking would not do that - omitting the -version-info
will libtool install libmy.so libmy.la libmy.a libmy-2.4.18.so and
executables would get hardlinked with the 2.4.18 version of your lib.
This background does also explain the default dll name for a win32
target : libtool will choose to make up libmy-2-4.dll for this
version spec.
Unlike the older/straight ac_set_releaseinfo_versioninfo this macro
does set the three parts MAJOR_VERSION.;MINOR_VERSION.MICRO_VERSION
from the VERSION-spec *and* does also ac_subst them like the two INFOs
*and* the three version-parts are ac_defined numerically too.
If you prefer a two-part VERSION-spec, the VERSION_REL will still be set,
either to the host_cpu or just a simple "00", so watch out.
You may add sublevel parts like "1.4.2-ac5" where the sublevel is
just killed from these versioninfo/releasinfo substvars.