Hi Merijn, thanks for the reply!
h.m.br...@xs4all.nl wrote: > rosenfield.alb...@gmail.com wrote: > > requiring DBI::PurePerl will, when not found, install DBI, > which includes DBI and DBI::PurePerl. Actually it seems that requiring DBI::PurePerl simply causes absolutely nothing to be installed from CPAN, rather than DBI. It's as if the requirement wasn't there, for some reason. > The first will only not be installed if it cannot be compiled. According to the DBI documentation, this has not been implemented, and DBI plus DBI::PurePerl will simply fail to install entirely if the C stage fails for whatever reason. See the parenthesised note at bottom of INSTALLATION paragraph: http://search.cpan.org/~timb/DBI-1.610_90/lib/DBI/PurePerl.pm#INSTALLATION > It looks like you have no option but to require nothing, and try to > "require DBI::PurePerl" during Makefile.PL time maybe. Okay. That's a no-go. When I try it, I run into this issue: ================================= Subroutine DBI::SQL_ALL_TYPES redefined Subroutine DBI::SQL_ARRAY redefined Subroutine DBI::SQL_ARRAY_LOCATOR redefined Subroutine DBI::SQL_BIGINT redefined Subroutine DBI::SQL_BINARY redefined Subroutine DBI::SQL_BIT redefined Subroutine DBI::SQL_BLOB redefined ... etc ... Subroutine _install_method redefined Subroutine _new_handle redefined Subroutine _setup_handle redefined Prototype mismatch: sub DBI::constant () vs none Subroutine constant redefined Subroutine trace redefined Subroutine _get_imp_data Subroutine _svdump redefined ... etc ... dbih_getcom handle DBI::dr=HASH(0x2beb77c) is not a DBI handle (has no magic) dbih_getcom handle DBI::dr=HASH(0x2beb77c) is not a DBI handle (has no magic) (in cleanup) dbih_getcom handle DBI::dr=HASH(0x2beb77c) is not a DBI handle (has no magic) during global destruction. (in cleanup) dbih_getcom handle DBI::dr=HASH(0x2b4b8bc) is not a DBI handle (has no magic) during global destruction. ================================= It seems that DBI gets confused if in one module (fx the driver), there is "use DBI::PurePerl", while in another module there is "use DBI". (I guess it's a nice trick for enumerating DBI internals though ;-).) >> [...snip...] > > Why would someone install DBI::PurePerl with a working XS version? Hm? I think we're talking besides each other here. > In order to do something similar with DBI, DBI should be renamed to > DBI::XS (or DBI_XS) and a new wrapper called DBI can at runtime select > either DBI::XS or DBI::PurePerl whatever is available. If this path > would be chosen, then it would be `normal' to also install > DBI::PurePerl because now the end-user has an option. Okay. Seems perfectly reasonable to split the two. I've seen this with other packages as well. This approach works great with Digest::SHA versus Digest::SHA::PurePerl, both with regard to Module::Build interaction and in "use" code: BEGIN { # Use C implementation of SHA if available (faster). eval { require Digest::SHA1; Digest::SHA1->import("sha1"); }; # Otherwise fall back to the Perl implementation. if ($@) { require Digest::SHA::PurePerl; Digest::SHA::PurePerl->import("sha1"); } } Works like a charm. Seems like the battle plan would be simple enough: 1) Determine code shared by current DBI and DBI-PP and put it into new "DBI". 2) Copy/paste the above auto-detection code into "DBI", to switch between DBI-XS and DBI-PP. 3) Put the XS parts into DBI-XS. 4) Put PurePerl.pm into DBI-PP. 5) Test all CPAN modules that depend on DBI to see if they still work. Then there is the question of whether these modules should still be contained in one CPAN package, or be split into three. You can avoid fuzzing with makefiles and how-to-skip-C-compilation if you just make three CPAN packages. If you look at module installers and the CPAN's "dslip" etc, these are other factors that also indicate that three distinct packages is the best way to go. There is maybe the risk that people would start doing "use DBI::PP/XS" instead of "use DBI" if they see separate packages on CPAN. But I think that is easily alleviated by writing in the docs that "use DBI" is correct. A measure could even be added to prevent a wrong "use", for example an internal parameter to "use DBI::PP" and "use DBI::XS" such that the use line fails with an error message if the "secret parameter" known only to DBI is not included. Anyhoo, I'm getting a bit far into the details. > FWIW I am not the one going to implement this. May I enquire why not? Where do you see trouble brewing? If there be consensus, I'd be happy to expend some time and effort. Or perhaps donate money to someone with greater skill than myself to do it :-).
