Feature Requests item #1578577, was opened at 2006-10-16 16:18
Message generated for change (Comment added) made by pcmacdon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=512948&aid=1578577&group_id=65979

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: version number in header

Initial Comment:
As libdbi evolves and functions are added
it might be useful to put
a version number in the dbi.h header ala Tcl.  eg.

#define DBI_VERSION "8.1"
#define DBI_VERSION_MAJOR "8"
#define DBI_VERSION_MINOR "1"

and would save doing bit hit and miss things like

#ifdef DB_TYPES_NULL
...
#endif



----------------------------------------------------------------------

>Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-22 08:53

Message:
Logged In: YES 
user_id=190660

I got the cvs head to build (after wrestling with autoconf
for a while) and it is now building and producing:

  libdbi.so.0.0.5

Are you planning to roll this version number to 8.2 somehow?

I don't know.  It's probably just me,  but I don't
see why you don't just manually hardcode the version number
in there rather than rely on the rather fragile and
intractible structure provided by autoconf.  It seems
like another level of indirection that is not really needed.

my 2c.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-18 13:21

Message:
Logged In: YES 
user_id=85809

I've checked in the suggested changes. With the current CVS
version you can access the libtool interface version info
through the defines called LIBDBI_LIB_CURRENT,
LIBDBI_LIB_REVISION, and LIBDBI_LIB_AGE. These numbers do
not have much in common with the libdbi version numbers, but
they are supposed to reflect all changes to the libdbi API
in future releases.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-18 08:55

Message:
Logged In: YES 
user_id=85809

Oh, I almost forgot that. To create a header file that
defines these values for other apps I'd suggest to let
configure create dbi.h from a dbi.h.in file using the
AC_CONFIG_FILES macro. This performs the necessary
substitutions.

----------------------------------------------------------------------

Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-18 08:31

Message:
Logged In: YES 
user_id=190660

As long as the version number ends up in the dbi.h file.
This because user/compiler may not have access to source.
So if that is what happens, great.
I'm assuming this would involve something like:

#define DBI_VERSION_MAJOR @LIB_CURRENT@
#define DBI_VERSION_MINOR @LIB_REVISION@

in a 'dbi-version.h.in' file, which would be included by
dbi.h


----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-18 04:32

Message:
Logged In: YES 
user_id=85809

I think this is less hairy than I thought. configure.in
defines LIB_CURRENT=0, LIB_REVISION=5, LIB_AGE=0 which is
later used in Makefile.am to construct the -version-info
option for libtool. It should suffice to add
"-DLIB_CURRENT=\"@[EMAIL PROTECTED]" and so on to AM_CPPFLAGS in
order to make these values available for C code.

Using the interface version of libtool has the added benefit
that developers using libdbi do not have to figure out which
libdbi version uses which interface.

Would that solve your needs for TclDBI?

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-18 00:54

Message:
Logged In: YES 
user_id=85809

I see. But before adding defines manually, I'd like to
investigate whether these values can be generated from the
libtool versioning information. Currently libdbi does not
use libtool versioning correctly (the version has remained
the same since the project started). I'd greatly appreciate
if someone could lend me a hand in setting up the libtool
versioning properly and in figuring out how to propagate
this information into a header file.

----------------------------------------------------------------------

Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-17 20:43

Message:
Logged In: YES 
user_id=190660

I should add that the main use for this feature
is for TclDBI, which may be compiled against
multiple versions of LibDBI.

----------------------------------------------------------------------

Comment By: Peter MacDonald (pcmacdon)
Date: 2006-10-17 10:39

Message:
Logged In: YES 
user_id=190660

Yes, am aware of the dbi_version() et al functions
which work great for run-time, but not compile-time.
8.1 contained new functions that were not found in 7.1,
and there is no easy way to detect this at compile time.

Here is an example extract of what I'm doing now:

#ifdef DBI_VALUE_NULL
  if (!dbi_conn_quote_string(h->conn, &cpq)) {
    ...
  }
#else
  if (!dbi_driver_quote_string(dbi_conn_get_driver(h->conn),
&cpq)) {
     ...
  }
#endif

This works for 7.1-8.1, but will not for 9.1 (when it comes
out).
Version strings in the header will allow something like:

#define DBI_VERSION "9.1"
#define DBI_VERSION_MAJOR 9
#define DBI_VERSION_MINOR 1

/* ... */

#if (!defined(DBI_VERSION))
/* ... */
#elif ((DBI_VERSION_MINOR == 1) && (DBI_VERSION_MAJOR==9))
/* ... */
#else
/* ... */
#endif


----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-17 07:29

Message:
Logged In: YES 
user_id=85809

Are you aware of the current version facilities in libdbi?

const char *dbi_version() returns a string containing the
libdbi version

const char *dbi_driver_get_version(dbi_driver Driver)
returns a string containing the version of the database driver

Both libdbi and libdbi-drivers use the version value set in
configure.in. Having the version information in one spot
only greatly simplifies maintenance. Using functions instead
of defines to access the version values is preferable
because functions allow your code to adapt dynamically to
the installed versions of the library and the drivers.
defines create executables that are adapted to a particular
version at build time.

We should think about making the version information easier
to parse though. Strings do not lend themselves to easy
comparison. One way to fix this is to add functions that
return the version as an integer value, e.g. computed as
series*10000 + major*100 + minor, resulting in something
like 801 for version 0.8.1. A similar computation is used in
the dbi_conn_get_engine_version() function which returns the
version of the database engine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=512948&aid=1578577&group_id=65979

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel

Reply via email to