view release on metacpan or  search on metacpan

src/judy-1.0.5/configure.ac  view on Meta::CPAN

AC_PREREQ(2.57)
AC_INIT(Judy, 1.0.5, dougbaskins@yahoo.com)

AM_MAINTAINER_MODE

dnl Turn on automake, and pass it the PACKAGE_NAME and PACKAGE_VERSION, too.
AM_INIT_AUTOMAKE($PACKAGE_NAME, $PACKAGE_VERSION)

dnl Tell autoconf we want to keep our preprocessor defines in a header named
dnl config.h.  This keeps automake from passing a zillion -D directives to
dnl the C compiler.
AM_CONFIG_HEADER([config.h])

dnl==========================================================================
dnl WARNING - WARNING - Shared Library Versioning - WARNING - WARNING
dnl==========================================================================
dnl This is the most dangerous part of this file--making a mistake here can
dnl cause massively painful chaos for libJudy developers, and potentially
dnl even end users.  So PLEASE pay attention, and read up on the theory of
dnl shared library versioning.  Tens of thousands of Linux users (and several
dnl QA departments) may thank you someday.
dnl
dnl There are two major concerns:
dnl
dnl   1) When changing the libJudy ABI (application binary interface),
dnl      VERSION_INFO *must* be updated according to libtool's rules.  Failure
dnl      to do this will make applications using libJudy dump core, typically
dnl      under obscure conditions on user systems.  I won't attempt to
dnl      explain these rules here; please see 'info libtool' for details.
dnl
dnl   2) When changing the libJudy ABI, it is also desirable to make libJudy
dnl      "parallel installable".  This means that it should be possible to
dnl      install development headers and libraries for more than one version
dnl      of libJudy at once.  Failure to do this may cause problems for
dnl      Linux distributions which include libJudy.  (For example, it's
dnl      impossible to switch between libpng2-dev and libpng3-dev on a
dnl      Debian system without uninstalling and reinstalling both the Gnome
dnl      and KDE SDKs.)  For more information, do a Google search for
dnl      "parallel installable".
dnl
dnl Right now, this package only provides the mechanisms to handle concern
dnl (1).  Concern (2) is slightly more complicated, and will require some
dnl careful thinking.  Fortunately, concern (2) doesn't become important
dnl until other SDKs rely on the libJudy SDK.
dnl
dnl Of course, it's safe to avoid changing the libJudy ABI. :-)
dnl 
dnl The version scheme used by Libtool tracks interfaces, where an interface is
dnl the set of exported entry points into the library. All Libtool libraries
dnl start with -version-info set to 0:0:0 - this will be the default version
dnl number if you don't explicitly set it on the Libtool link command line. The
dnl meaning of these numbers (from left to right) is as follows:
dnl 
dnl  current:
dnl     The number of the current interface exported by the library. A current
dnl     value of 0, means that you are calling the interface exported by this
dnl     library interface 0.
dnl
dnl  revision:
dnl     The implementation number of the most recent interface exported by this
dnl     library. In this case, a revision value of 0 means that this is the
dnl     first implementation of the interface.
dnl 
dnl     If the next release of this library exports the same interface, but has
dnl     different implementation (perhaps some bugs have been fixed), the
dnl     revision number will be higher, but current number will be the same. In
dnl     that case, when given a choice, the library with the highest revision
dnl     will always be used by the runtime loader.
dnl