Re: Problems with ppport.h and dbipport.h
On 25/10/10 11:40, Tim Bunce wrote: On Fri, Oct 22, 2010 at 06:59:57PM +0100, Martin J. Evans wrote: I've released a DBD::ODBC requiring Perl 5.8 but included the use of my_snprintf (from ppport.h) which unfortunately was not defined until 5.9.4. Fair enough, my fault but I have no way of fixing it (other than reversing my_snprintf back to sprintf) because of the way DBI includes dbipport.h (alias ppport.h). In DBI, dbipport.h is a renamed ppport.h generated by Devel::PPPort and is included from DBIXS.h which all DBDs include - presumably the idea was to save DBDs from having to keep up to date with ppport.h. In DBI 1.609, dbipport.h was updated (by H Merijn Brand I think) to the latest Devel::PPPort 3.19 version but I'm not convinced dbipport.h is always kept in sync with ppport.h. However, because DBIXS.h includes dbipport.h as #include dbipport.h I cannot override DBI's copy with a newer version in DBD::ODBC and hence I cannot fix my my_snprintf issue the way I'd like which is to include with DBD::ODBC a newer ppport.h as dbipport.h. In the case reported to me the user has an old DBI pre 1.609 which has a massively out of date ppport.h and he cannot upgrade DBI but he cannot install the latest DBD::ODBC. If that #include dbipport.h was changed to #include dbipport.h I could at least release a DBD::ODBC including the latest ppport.h as dbipport.h and the problem is fixed. I know this won't help today but if this had been done in the past I would at least have had the option to fix it locally in DBD::ODBC today. As a result, I'd like to change that include in DBIXS.h to add this flexibility in the future. Any objections? None. Done, thanks. I didn't add a change entry. Sometimes I'm unsure whether to or not. In DBD::ODBC I pretty much log everything but I'm not sure of your policy in DBI. On Sat, Oct 23, 2010 at 10:53:20PM +0100, Martin J. Evans wrote: Given I've had no response to this (other than Tux on #dbi who did not object) I will make the suggested change in the next few days (I don't think it hurts but it allows DBDs to override the dbipport.h with a newer version). However, since DBD::ODBC is broken with older DBIs I'm going to make the next DBD::ODBC release dependent on DBI 1.609. Okay. Also done in subversion but not released yet. The next release of DBD::ODBC (1.26_1 only in subversion soon but not as yet) has over 200 code block changes to the codebase mostly to a) complete the move to ODBC 3.0 and require an ODBC Driver Manager and b) refactor the code to remove redundant code. My next step is to investigate tracing as I'm having a lot of problems with people settting the trace level to less than 15 or setting a trace level for connections which is problematic. Please explain (in a new thread). Will do when I get a proper chance to research it fully. The next development release of DBD::ODBC should be treated with caution as it contains a huge number of codebase changes. I hope to have this released in the next week. Thanks Martin. Tim. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: Problems with ppport.h and dbipport.h
On Mon, Oct 25, 2010 at 01:05:52PM +0100, Martin J. Evans wrote: As a result, I'd like to change that include in DBIXS.h to add this flexibility in the future. Any objections? None. Done, thanks. I didn't add a change entry. Sometimes I'm unsure whether to or not. In DBD::ODBC I pretty much log everything but I'm not sure of your policy in DBI. Generally best to err on the side of adding it. I'll always do a prune-n-polish before releasing and may tweak or remove things that don't seem sufficiently 'significant' to the general audience. In this case I probably would have deleted it :) Thanks! Tim.
Problems with ppport.h and dbipport.h
I've released a DBD::ODBC requiring Perl 5.8 but included the use of my_snprintf (from ppport.h) which unfortunately was not defined until 5.9.4. Fair enough, my fault but I have no way of fixing it (other than reversing my_snprintf back to sprintf) because of the way DBI includes dbipport.h (alias ppport.h). In DBI, dbipport.h is a renamed ppport.h generated by Devel::PPPort and is included from DBIXS.h which all DBDs include - presumably the idea was to save DBDs from having to keep up to date with ppport.h. In DBI 1.609, dbipport.h was updated (by H Merijn Brand I think) to the latest Devel::PPPort 3.19 version but I'm not convinced dbipport.h is always kept in sync with ppport.h. However, because DBIXS.h includes dbipport.h as #include dbipport.h I cannot override DBI's copy with a newer version in DBD::ODBC and hence I cannot fix my my_snprintf issue the way I'd like which is to include with DBD::ODBC a newer ppport.h as dbipport.h. In the case reported to me the user has an old DBI pre 1.609 which has a massively out of date ppport.h and he cannot upgrade DBI but he cannot install the latest DBD::ODBC. If that #include dbipport.h was changed to #include dbipport.h I could at least release a DBD::ODBC including the latest ppport.h as dbipport.h and the problem is fixed. I know this won't help today but if this had been done in the past I would at least have had the option to fix it locally in DBD::ODBC today. As a result, I'd like to change that include in DBIXS.h to add this flexibility in the future. Any objections? Martin
Re: ppport.h
H.Merijn Brand wrote: On Fri, 23 Oct 2009 20:10:29 +0100, Martin J. Evans martin.ev...@easysoft.com wrote: I noticed DBI was upgraded in subversion to the latest ppport.h (in dbipport.h) and the recommendations that ppport.h has made. :) dbipport.h seems to be ppport.h from Devel::PPPort. Correct The DBI::DBD docs say to copy dbivport.h from the latest DBI distribution to your DBD distribution - which I have done again - I am happy with this and understand it. Good I have implemented the recommendations that perl ppport.h dbdimp.c has made in DBD::ODBC. \o/ However, perl ppport.h dbdimp.c for DBD::ODBC suggests adding ppport.h to DBD::ODBC's dbdimp.c and including it in the DBD::ODBC distribution. Remove that line. You need only one! I cannot do that since I'll get dbipport.h and ppport.h and redeclarations of macros. Correct. The recommendation is such, that to keep as close to the actual DBI, compiler with the ppport.h that was shipped with DBI. In theory it should not matter, but we want to be sure. Another reason to ship dbipport.h, is that it is likely to be more recent than the one shipped with perl itself. I may be missing something but I don't understand why DBI includes ppport.h as dbipport.h since it stops me including a newer version of pport.h. I expected the way this would work is that when building DBI, you'd get DBI's copy of ppport.h but when building a DBD::* you'd get DBD::*'s copy of ppport.h. What to do? Use DBI's version, but using a *recent* version of Devel::PPPort is fine too. I intend to keep ppport.h in DBI `recent' as long as Tim permits me to I don't get but using a *recent* version of Devel::PPPort is fine too. How can you do this? DBIXS.h does #include dbipport.h so the one I have in /usr/local/lib/perl/5.8.8/auto/DBI/dbipport.h is always picked up even if I put my own copy of ppport.h as dbipport.h in DBD::ODBC distribution. It would have to be: #include dbipport.h to pick up a local one first. So as it stands, if I analyze my dbdimp.c with the latest Devel::PPPort and made changes using new macros then someone attempts to install DBD::ODBC with an old DBI (with an older ppport.h missing the new macro I have used) they may get undefined macros. i.e., there does not seem to be a way for me to override dbipport.h with a newer one. Martin
ppport.h
I noticed DBI was upgraded in subversion to the latest ppport.h (in dbipport.h) and the recommendations that ppport.h has made. dbipport.h seems to be ppport.h from Devel::PPPort. The DBI::DBD docs say to copy dbivport.h from the latest DBI distribution to your DBD distribution - which I have done again - I am happy with this and understand it. I have implemented the recommendations that perl ppport.h dbdimp.c has made in DBD::ODBC. However, perl ppport.h dbdimp.c for DBD::ODBC suggests adding ppport.h to DBD::ODBC's dbdimp.c and including it in the DBD::ODBC distribution. I cannot do that since I'll get dbipport.h and ppport.h and redeclarations of macros. I may be missing something but I don't understand why DBI includes ppport.h as dbipport.h since it stops me including a newer version of pport.h. I expected the way this would work is that when building DBI, you'd get DBI's copy of ppport.h but when building a DBD::* you'd get DBD::*'s copy of ppport.h. What to do? Martin
Re: ppport.h
On Fri, 23 Oct 2009 20:10:29 +0100, Martin J. Evans martin.ev...@easysoft.com wrote: I noticed DBI was upgraded in subversion to the latest ppport.h (in dbipport.h) and the recommendations that ppport.h has made. :) dbipport.h seems to be ppport.h from Devel::PPPort. Correct The DBI::DBD docs say to copy dbivport.h from the latest DBI distribution to your DBD distribution - which I have done again - I am happy with this and understand it. Good I have implemented the recommendations that perl ppport.h dbdimp.c has made in DBD::ODBC. \o/ However, perl ppport.h dbdimp.c for DBD::ODBC suggests adding ppport.h to DBD::ODBC's dbdimp.c and including it in the DBD::ODBC distribution. Remove that line. You need only one! I cannot do that since I'll get dbipport.h and ppport.h and redeclarations of macros. Correct. The recommendation is such, that to keep as close to the actual DBI, compiler with the ppport.h that was shipped with DBI. In theory it should not matter, but we want to be sure. Another reason to ship dbipport.h, is that it is likely to be more recent than the one shipped with perl itself. I may be missing something but I don't understand why DBI includes ppport.h as dbipport.h since it stops me including a newer version of pport.h. I expected the way this would work is that when building DBI, you'd get DBI's copy of ppport.h but when building a DBD::* you'd get DBD::*'s copy of ppport.h. What to do? Use DBI's version, but using a *recent* version of Devel::PPPort is fine too. I intend to keep ppport.h in DBI `recent' as long as Tim permits me to Martin Thanks for testing and checking -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
