Re: [libdbi-devel] Library version macro

[Markus H. <mar...@mh...>]

Quoting Andreas Ericsson <ae...@op...>:

>> 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
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de