Quoting Andreas Ericsson <a...@op5.se>:
>> LIB_{CURRENT,REVISION,AGE} for quite a while.
>
> But aren't those determining the .so-version as well? If so, it wouldn't
> be correct to update them with micro-releases, since the linker would
> believe a later version is incompatible with an earlier one.
>
They do, but in a reasonable way. LIB_CURRENT is the API version
number proper. LIB_REVISION numbers the revisions that do not change
the API (what you call "micro-releases"). LIB_AGE indicates how many
version numbers the current release is backwards-compatible with. The
runtime linker is able to figure out everything from these three
numbers. For example, bugfixes bump up LIB_REVISION without affecting
the other numbers. Your linker will be happy to run any of your
programs with this bug-fixed version. If we add functions though,
LIB_CURRENT gets bumped up, and your linker will refuse to run your
programs unless LIB_AGE permits to do so.
> The best trick is probably to utilize the vcs versioning numbers and
> use a script to cut releases. Sadly, I have no idea how to make that
> work in cvs, although I could do it blindfolded in git, hint hint ;-)
>
This might work in svn, but not in cvs, as the latter uses revision
numbers for individual files rather than for repositories. A critical
change in one of the files would not be reflected in the version
number of another file which is used to number the releases.
> Sounds awesome, but I'd still invite you to give some serious thought
> to having it be updated automagically when you cut a release. Any manual
> labour is bound to go stale sooner or later.
>
We've had this discussion in the past. I'm pretty sure the current way
of dealing with versioning does involve the minimum amount of work
possible. It is of course tempting to use VCS revision numbers for
versioning, but in order to avoid runtime linker problems we have to
update the LIB_XYZ constants anyway. configure.in is set up to promote
this information to dbi.h automatically, so there is no further manual
work required. As a side effect we have to deal only with one set of
numbers.
>> For the time being you'd have to write configure tests which look
>> for the functions that you want to call. For libdbi releases up to
>> 0.8.3 this is the only reliable way to test for the presence of
>> these functions. Let me know if you need further assistance.
>>
>
> Ugh. That's more complexity than it's worth. I've just hacked around it
> using a wrapper for dbi_conn_quote_string_copy() atm. It suffices for
> my needs. Thanks for the tip though. I'll look into it if I run into
> anything I can't work around in some other way.
>
Hey, I know it's cumbersome, but it is not that hard. All you need to
do is to write a three-line app which calls the desired function.
autoconf has macros to detect whether linking this app is going to
work. Just let me know if there is a problem that you can't "wrap"
around.
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
