view release on metacpan or  search on metacpan

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

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
dnl   age:
dnl     The number of previous additional interfaces supported by this library.
dnl     If age were 2, then this library can be linked into executables which
dnl     were built with a release of this library that exported the current
dnl     interface number, current, or any of the previous two interfaces.
dnl
dnl By definition age must be less than or equal to current. At the outset, only
dnl the first ever interface is implemented, so age can only be 0.
dnl 

VERSION_INFO="-version-info 1:3:0"
AC_SUBST(VERSION_INFO)

dnl==========================================================================
dnl Flavors
dnl==========================================================================
dnl Judy can be compiled in one of three flavors: "product" (the default),
dnl "debug", or "cov".  We allow the user to select flavors using
dnl --enable-debug and --enable-ccover arguments to automake, which is
dnl the typical way of doing things.
dnl 
dnl Note how we perform string comparison:
dnl
dnl   if test "x$enable_debug" = xyes; then
dnl
dnl We do several odd things here:
dnl
dnl   1) We use 'test' instead of '[ ]' for shell portability.
dnl   2) We prefix strings with 'x' when comparing them, to protect against
dnl      empty strings.
dnl   3) We ALWAYS quote user-supplied shell variables, to protect against
dnl      embedded spaces.
dnl
dnl The results of this test aren't used anywhere yet.

dnl Keep the user entertained.
AC_MSG_CHECKING(which flavor to build)

dnl Process our --enable-debug argument.
AC_ARG_ENABLE(debug,
              AC_HELP_STRING([--enable-debug],
                             [enable debugging features]),
              , enable_debug=no)
if test "x$enable_debug" != xyes -a "x$enable_debug" != xno; then
   AC_MSG_ERROR(You may not pass an argument to --enable-debug)
fi

dnl Process our --enable-ccover argument.
AC_ARG_ENABLE(ccover,
              AC_HELP_STRING([--enable-ccover],
                             [enable use of ccover code coverage tools]),
              , enable_ccover=no)
if test "x$enable_ccover" != xyes -a "x$enable_ccover" != xno; then
   AC_MSG_ERROR(You may not pass an argument to --enable-ccover)
fi

dnl Determine our flavor.
if test "x$enable_debug" = xyes -a "x$enable_ccover" = xyes; then
   AC_MSG_ERROR(You may not use --enable-debug and --enable-ccover together)
elif test "x$enable_debug" = xyes; then
   FLAVOR=debug
elif test "x$enable_ccover" = xyes; then
   FLAVOR=cov
else
   FLAVOR=product
fi

dnl Define FLAVOR in our makefiles.
AC_SUBST(FLAVOR)

dnl Tell the user what flavor we've decided to build.
AC_MSG_RESULT($FLAVOR)


dnl==========================================================================
dnl Checks for Programs
dnl==========================================================================
AC_PROG_CC