Hi there,
Quoting Florian Forster <o...@verplant.org>:
> I think you're making the (common) mistake to confuse API and ABI
> versions. It is not useful for a C program (or its compiler) to know the
> ABI version. It's used by the linker to figure out if an installed
> version of the library is compatible with the library used when
> compiling and linking the program, i. e. when it is (about to be) run.
>
> The API version *is* useful for the C program and its compiler to know,
> so it knows which features are available. In contrast to the ABI
> version, this information is used at compile time.
>
I'm aware of this distinction, although it doesn't hurt to think about
it once in a while.
> By all means, introduce version testing macros/defines, such as:
> #define LIBDBI_MAJOR 0
> #define LIBDBI_MINOR 8
> #define LIBDBI_PATCH 3
I'm not going to do that, as discussed before on this list. In brief,
we forgot to update the libtool interface version info in the past. In
the worst case your suggestion will cause us to forget to uptate the
interface version *and* the library version :-(
> #define LIBDBI_VERSION ((1000000 * LIBDBI_MAJOR) \
> + (1000 * LIBDBI_MINOR) \
> + LIBDBI_PATCH)
>
I'll be happy to do something along these lines, based on the version
numbers that we have.
>
> But mis-using the ABI version numbers for this purpose is evil, Evil,
> EVIL!
>
Not quite. The warning in the libtool manual about not forcing the
library version into the interface version is absolutely correct. But
instead of abusing the library version as an interface version, I'd
like to use the interface version as the library version. I've never
understood why a library needs a version number that is different from
the interface number. What changes would justify increasing
LIBDBI_MAJOR without affecting LIBDBI_LIB_CURRENT? Why would changes
that require a new interface be reflected by an increase of
LIBDBI_MINOR instead of LIBDBI_MAJOR? Also, a library isn't something
that needs to be marketed via version numbers. We'll never jump from
1.2 to 5.0 just because some competitor has 4.0.
So, to sum it up:
Next release, called "1.0":
LIBDBI_LIB_CURRENT 1
LIBDBI_LIB_REVISION 0
LIBDBI_LIB_AGE 1
If we fix some bugs in that release, we'll have "1.1":
LIBDBI_LIB_CURRENT 1
LIBDBI_LIB_REVISION 1
LIBDBI_LIB_AGE 1
If we add further functions in a backwards compatible way, we'll have "2.0":
LIBDBI_LIB_CURRENT 2
LIBDBI_LIB_REVISION 0
LIBDBI_LIB_AGE 2
All of this accessible to the compiler via:
#define LIBDBI_VERSION ((1000 * LIBDBI_LIB_CURRENT) \
+ LIBDBI_LIB_REVISION)
And, all updates to these numbers done in one place in configure.in.
Would that cause any grief?
regards,
Markus
--
Markus Hoenicka
markus.hoeni...@cats.de
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
libdbi-devel mailing list
libdbi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-devel
