[Libdbi-drivers-devel] [ libdbi-drivers-Feature Requests-1578577 ] version number in header
Feature Requests item #1578577, was opened at 2006-10-17 01:18 Message generated for change (Comment added) made by mhoenicka You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=512948aid=1578577group_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: Open Priority: 5 Private: No 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: Markus Hoenicka (mhoenicka) Date: 2006-10-25 09:29 Message: Logged In: YES user_id=85809 The answer is no if you expect the next release to contain something like #define DBI_VERSION_MAJOR 8 The answer is yes if you expect the next release to contain a mechanism that both creates definitions that you can use to base your #ifdef tests on and that also ensures that the runtime linker loads the appropriate library that your code was linked against. Please bear in mind that the only difference to your original suggestion is that we move away from arbitrary library version numbers towards version numbers based on the interface version. I apologize if my reasoning behind this decision was too confusing or too lengthy to follow. To read up the reasons in native English and CS lingo, please peruse the following documents: http://sources.redhat.com/autobook/autobook/autobook_91.html#SEC91 http://www.gnu.org/software/libtool/manual.html#Versioning -- Comment By: Peter MacDonald (pcmacdon) Date: 2006-10-25 01:14 Message: Logged In: YES user_id=190660 All those things may be true, but the Feature Request was: version number in header. I may be confused by your answer, but it sounds like no. -- Comment By: Markus Hoenicka (mhoenicka) Date: 2006-10-23 11:02 Message: Logged In: YES user_id=85809 I absolutely agree with the purpose of this request. However you seem to forget that compilation against a particular version of libdbi is only half of a developers job. The other half is ensuring that the compiled app also links to the installed version of the library at runtime. If you maintain one set of version numbers for the compiler, and another set for the runtime linker, you will eventually end up with an application that builds but does not load or would load if only you could build it. From that I think we agree that both the application developer and the runtime linker should work with the same version numbers. The question is which numbers we should use. We can freely choose a version number for our project, but as stated before we cannot force a particular library version if we use libtool. libtool is portable and has served the community for more than 10 years. I do not expect myself to be more intelligent than libtool, so I suggest to use it just as it is. Therefore, it is not an additional level of indirection to ask developers to use the interface version instead of the (arbitrary) project version. In contrast, asking developers and package maintainers to use one set of numbers for compiling and another set of numbers for packaging and ensuring runtime linking *is* another level of indirection. This has so far just not been apparent as no one of the libdbi developers, including me, took care to maintain the libtool versioning. Try building an executable on a box using the current libdbi version and run it on a box with 0.7.1 installed. You'll get boatloads of undefined symbol errors instead of the clear message that the library that the executable was linked against is missing from your system. This is the kind of confusion that our version numbers are supposed to prevent. BTW LIB_CURRENT is as meaningless to the compiler as DBI_VERSION_MAJOR or any other definition. It is the developers job to make sense of it, and I am convinced that using the interface numbers instead of release version numbers simplify the task if you look at the whole chain of events, up to the end-user who runs your application. To make things a little easier to digest I'd suggest to bump up the major version number of the next release that changes the interface. We're currently at 0.8.1. Here the major version is 0, not 8 (!). The interface version (LIB_CURRENT) is also 0. The implementation number (LIB_REVISION) unfortunately got stuck at 5 due to my neglect, and should better be 8. Let the next incompatible change create
[Libdbi-drivers-devel] [ libdbi-drivers-Feature Requests-1578577 ] version number in header
Feature Requests item #1578577, was opened at 2006-10-17 01:18
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=512948aid=1578577group_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: Open
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: Markus Hoenicka (mhoenicka)
Date: 2006-10-18 17: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 17: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 13: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 09: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-18 05: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 19: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 16: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
[Libdbi-drivers-devel] [ libdbi-drivers-Feature Requests-1578577 ] version number in header
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=detailatid=512948aid=1578577group_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: Open
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-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*1 + 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=detailatid=512948aid=1578577group_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=lnkkid=120709bid=263057dat=121642
___
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
