[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',
			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

> > > 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
# 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},
  : -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 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