[DBD-SQLite] DBD::SQLite and CPAN
Curtis Jewell
lists.perl.dbd-sqlite at csjewell.fastmail.us
Fri Jun 19 19:16:20 GMT 2009
On Fri, 19 Jun 2009 13:26 -0500, "David Dooling"
<banjo at users.sourceforge.net> wrote:
> > > Two possible solutions I can think of:
> > >
> > > 1) configure_requires. Doesn't help with old clients
> >
> > No, but it's the easiest way to help new ones. It can't hurt.
>
> This seems more applicable to DBD::SQLite than something that needs
> DBD::SQLite. Using that would require porting the entire DBD::SQLite
> build system to Module::Install (it currently uses
> ExtUtils::MakeMaker).
Yes, it does, and no, it wouldn't require switching to M::I, because the
capability is already in there!
DBD::SQLite's Makefile.PL includes this:
OPTIONAL( '6.46',
META_MERGE => {
configure_requires => {
'ExtUtils::MakeMaker' => '6.48',
'File::Spec' => '0.82', # This is not allowed to be computed
'DBI' => $DBI_required,
}, ...
so that if you have a client new enough to pick the configure_requires
line out of the META.yml, the problem should not arise in the first
place.
> > > 2) Use the 'Are we running under a CPAN shell' from the (now improved)
> > > Module::Install::AutoInstall.
> >
> > Do this, too. It will catch what the previous one does not.
>
> I'll try this (although I am not entirely sure if it will help; the
> docs are a little light).
>
> > > Oh, a bonus 3rd option.
> > >
> > > 3) Remove the check and delay it to the first test which does BAIL_OUT
> > > if DBI is too old.
> >
> > Does it even COMPILE if DBI is too old?
>
> It seems if DBI is a PREREQ_PM, both of these are moot since the
> appropriate version of DBI would be installed before compilation or
> testing.
True. The problem being that it requires DBI 1.57 just to build a
Makefile correctly. (although instead of running an eval {use DBI;
etc... }, the Makefile.PL should use MM->parse_version to find out the
version number, I would think...)
But you're right. By the time it needs to copy the files (during make
stage), you'd have the right version of DBI in there if you were using a
CPAN client.
Why it absolutely insists on the version in the Makefile.PL stage, I
don't know.
Personally, I'd make your module do something like this in order to
brute-force the issue: (heavily psuedocoded)
# All in core since 5.00504...
use ExtUtils::MakeMaker; # I think M::I loads it anyway.
use Config;
use File::Spec::Functions qw(catfile);
# Yes, I know this doesn't catch a DBI installed with local::lib or in a
PREFIX or INSTALL_BASE directory.
# I don't quite see how to do that easily in EU::MM/M::I style. Maybe
you do.
# M::B makes it easy enough - and it's what I use for a lot of things.
my $dbi_file = do {
-e catfile($Config{sitelib}, 'DBI.pl') ? catfile($Config{sitelib},
'DBI.pl')
: -e catfile($Config{vendorlib}, 'DBI.pl') ?
catfile($Config{vendorlib}, 'DBI.pl')
: undef;
}
if ((not defined $dbi_file) or (MM->parse_version($dbi_file) < 1.57)) {
if ($IN_CPAN) {
# Tell CPAN or CPANPLUS to install DBI, like M::AutoInstall does
it.Maybe figure out a way to make M::AI do it!
} else {
# Tell the user to install DBI
}
}
# process rest of makefile.
--Curtis
--
Curtis Jewell
swordsman at csjewell.fastmail.us
%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears
[I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]
More information about the DBD-SQLite
mailing list