On Sun, 5 Aug 2001, Jonathan Leffler wrote:
>Tim Bunce wrote:
>> On Thu, Jan 04, 2001 at 02:09:53PM +0100, H.Merijn Brand wrote:
>> > On Wed 01 Aug 2001 17:28, Tim Bunce <[EMAIL PROTECTED]> wrote:
>> > > Does anyone know of any DBI drivers that are implemented in XS
>> > > (ie C) that [do not] use the Driver.xst template file provided by
>> > > the DBI?
>> > What is it good for>
>>
>> It's the magic interface shim between XS and driver code. It's
>> mentioned several times in the DBI::DBD doc. You probably won't see
>> it in your sources because of the way the DBI makes it available to
>> you. [...snip...]
>> Your *.xs file should then contain *nothing* except:
>> [...editorial correction of Oracle to YourDriverName...]
>>
>> DBISTATE_DECLARE;
>> MODULE = DBD::YourDriverName PACKAGE = DBD::YourDriverName
>> INCLUDE: YourDriverName.xsi
>
>I know that the Informix.xs file in DBD::Informix contains more
>information than those 3 lines [...]
Tim,
I went and looked at Informix.xs, and it does contain a lot of other
stuff. I tried to use what you are asking me to document (using DBI
v1.19 and Perl 5.005_03, rather than 5.6.1), and it didn't compile -- it
didn't compile horribly! And I'm not referring to the stuff that I
removed that expected to show up as missing; the basic compilation to
Informix.o failed totally.
With just those three lines in the Informix.xs file (and comments top
and bottom), I got lots and lots of compilation errors, starting with:
Informix.xs:14: warning: type defaults to `int' in declaration of `DBISTATE_DECLARE'
Informix.xs:14: ANSI C forbids data definition with no type or storage class
Informix.c:30: warning: return-type defaults to `int'
Informix.c: In function `XS':
Informix.c:31: `dXSARGS' undeclared (first use in this function)
Informix.c:31: (Each undeclared identifier is reported only once
Informix.c:31: for each function it appears in.)
Informix.c:32: `dXSI32' undeclared (first use in this function)
Informix.c:33: `items' undeclared (first use in this function)
Informix.c:34: warning: implicit declaration of function `croak'
Informix.c:34: warning: implicit declaration of function `GvNAME'
Informix.c:34: warning: implicit declaration of function `CvGV'
Informix.c:34: `cv' undeclared (first use in this function)
Informix.c:36: `SV' undeclared (first use in this function)
Informix.c:36: `drh' undeclared (first use in this function)
Informix.c:36: warning: implicit declaration of function `ST'
I had to prefix this with '#include "Informix.h"' to get it to compile.
That file contains:
/*
* @(#)$Id: Informix.h,v 95.1 1999/12/23 18:42:00 jleffler Exp $
*
* Portions Copyright (c) 1994,1995 Tim Bunce
* Portions Copyright (c) 1995,1996 Alligator Descartes
* Portions Copyright (c) 1996,1997,1999 Jonathan Leffler
*
* You may distribute under the terms of either the GNU General Public
* License or the Artistic License, as specified in the Perl README file.
*/
/*TABSTOP=4*/
#ifndef INFORMIX_H
#define INFORMIX_H
#define NEED_DBIXS_VERSION 9
/* For ActiveState Perl on NT */
/* Change from Michael Kopchenov <[EMAIL PROTECTED]> */
#ifdef PERL_OBJECT
#define NO_XSLOCKS
class CPerlObj;
extern CPerlObj* pPerl;
#endif
#include <DBIXS.h> /* Installed by the DBI module */
#include "dbdimp.h" /* Informix implementation details */
#include <dbd_xsh.h> /* Installed by the DBI module */
#endif /* INFORMIX_H */
Is NEED_DBIXS_VERSION 9 still appropriate? I'd love to get rid of the
ActiveState botch (I confess I don't understand it). I also have
problems with some messing with fprintf for ActiveState Perl in the
current released version of Informix.xs:
/* For ActiveState Perl on NT */
/* Change from Michael Kopchenov <[EMAIL PROTECTED]> */
#ifdef PERL_OBJECT
#include "XSLock.h"
#undef fprintf
#define fprintf (fprintf)
#endif
Anybody know if that is necessary? What changes are required in the
debug code for PerlIO support?
I'd be willing to concede that the code should not need to know about
anything from dbdimp.h (though dbdimp.h is where you are supposed to map
dbd_login to the driver-specific name), but it needs both DBIXS.h and
dbd_xsh.h regardless -- I used the following Informix.xs and it compiled
but was not directly usable because of the name mapping problems.
#include <DBIXS.h>
#include <dbd_xsh.h>
DBISTATE_DECLARE;
MODULE = DBD::Informix PACKAGE = DBD::Informix
INCLUDE: Informix.xsi
Additionally, your assertion that it should contain nothing else means I
need to understand where to write some of the code that currently is in
Informix.xs. Some of it is plain junk that you don't want to know
about; some of it is about to become critical -- like the constant
function that declares a whole bunch of Informix-specific type names
when you say 'use DBD::Informix(ix_types);' in your file. That code is
XS code declared under the DBD::Informix module/package:
I32
constant()
PROTOTYPE:
ALIAS:
IX_SMALLINT = SQLSMINT
[...snip about 20 types...]
IX_BLOB = DBD_IX_SQLBLOB
CODE:
RETVAL = ix;
OUTPUT:
RETVAL
I assume that such routines do need to be in Informix.xs; if not, please
tell me where to put it. And it does need access to dbdimp.h because
that ensures that the names SQLSMINT and DBD_IX_SQLBLOB (in the fragment
that I've shown) are #defined.
I'm not clear how I should include a C-code data_sources() function into
the DBD::Informix driver. What I've got at the moment is indubitably
nasty (the main implementation is in Informix.xs, rather than just an
interface function), but please can you indicate what the XS-interface
should be for such code? I know this is not a majority pre-occupation
since for most drivers the data_sources method is pure Perl; it is not
possible to do it in pure Perl with Informix.
So, in modifying DBI::DBD, I think your example is missing the critical
'#include "Driver.h"' line from the required contents of the Driver.xs
file. And I'm not sure but I think your comments about 'and nothing
else' are too sweeping.
I note from scrutiny of the Informix.c code generated that DBI::DBD
should mention that dbd_db_login6 exists and that dbd_db_login is the
old deprecated interface. Obviously, dbd_db_login6 is the preferred
version because it passes the attributes parameter to the driver code.
I note that this important addition is not mentioned in the Changes file
anywhere, so I for one did not know I needed to implement it, though it
is presaged in the DBD::DBD.pm file. That allows me to remove a whole
heap of junk from the DBD::Informix code which was designed to work
around the absence of the attributes. I note that dbd_db_login6 was
present in DBI v1.06 but was not in DBI v1.02; I'm not sure exactly when
it was introduced.
>> I'd *really* love someone to write this up as a patch to the
>> lib/DBI/DBD.pm docs. Any volunteers?
Yes; I'll do it when I'm sure I know what to write.
>> Why is this important? Two main reasons:
>>
>> 1/ The Driver.xst file contains lots of important 'DBI logic' that's important
>> to not only do right, but maintain as the DBI evolves. Using Driver.xst
>> means you, driver authors, don't have to worry about that.
>>
>> 2/ The mechanism will probably play a key part in porting drivers to perl6.
--
Yours,
Jonathan Leffler ([EMAIL PROTECTED]) #include <disclaimer.h>
Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN
"I don't suffer from insanity; I enjoy every minute of it!"
PS: I'm not certain that my Informix login is authorized to post to
dbi-dev, so the rest of the world may not see this message until I
bounce it to dbi-dev from my home email address.
