develooper Front page | perl.perl5.porters | Postings from December 2012

JROBINSON grant report, #13

Thread Next
From:
Jess Robinson
Date:
December 18, 2012 11:49
Subject:
JROBINSON grant report, #13
Message ID:
op.wpigfpr31zpo48@insel

Mornin all,

As you may (or may not) have noticed, James has been working on a  
Java-based backed for Matt's Object::Remote tool (hitting CPAN soon, I'm  
told). In case you haven't, O::R itself is a tool for running Perl code on  
remote servers, expecting nothing but a copy of Perl installed on those  
servers. All the required modules are shipped over to the target server  
using FatPacker. The actual running of the code is done via a JSON based  
protocol which sends instructions like "create a new Widget", "run method  
X on the Widget object", "return results". Only the object IDs are passed  
around, the actual objects stay where they are created..

Anyway, long story short, we have a Java backend that follows the above  
principles, (except for the needing to copy Perl modules about), which we  
can install on Android, and then use Perl (on Android or remotely) to  
implement Android apps. Most of this was not done on grant time, as it was  
a side project.

Last week I did spend some grant time making RunPerl, the small on-Android  
testing app that I built, use Object-Remote-Java, and include a demo  
script that will manipulate the GUI. I also wrote some docs and a blog  
post, to show people what's possible. The post (with links to everything  
else), is at:  
http://desert-island.me.uk/~castaway/blog/2012-12-perl-on-android-christmas-fun.html

This gives a visual demonstration of the uses of all this work and was a  
nice break from grubbing around in Configure.

Matt himself was after trying it out, and is more interested in running  
Perl on his Android device to be able to develop Perl code for other uses.  
He asked me if I could get him DBI and DBD-SQLite compiled/installable. As  
this is something we need a solution for (compiling XS modules for the  
cross-compiled Perl), I did this on grant time as well. Luckily both these  
modules use ExtUtils::MakeMaker, like Perl core, so I just needed to patch  
for the attempts to actually load the (now cross-compiled) DBI.so on the  
host. This loading was all in aid of retrieving $DBI::VERSION, so I  
patched it to use ExtUtils::MakeMaker's parse_version instead.

These patches are not final, as they assume it's sat in the core cpan/ dir  
and being compiled during Perl core compilation. I suspect some check for  
$Config{usecrosscompile} instead will be better later.

diff -ru ./lib/DBI/DBD.pm  
/usr/src/perl/perl-cross-compile/repo/perl/cpan/DBI/lib/DBI/DBD.pm
--- ./lib/DBI/DBD.pm	2012-02-04 20:51:40.000000000 +0000
+++  
/usr/src/perl/perl-cross-compile/repo/perl/cpan/DBI/lib/DBI/DBD.pm	2012-12-16  
15:11:29.000000000 +0000
@@ -3283,7 +3283,7 @@

  BEGIN {
      $is_dbi = (-r 'DBI.pm' && -r 'DBI.xs' && -r 'DBIXS.h');
-    require DBI unless $is_dbi;
+    require DBI unless $is_dbi or $ENV{PERL_CORE};
  }

  my $done_inst_checks;
@@ -3437,13 +3437,27 @@
  sub dbd_dbi_arch_dir {
      _inst_checks();
      return '$(INST_ARCHAUTODIR)' if $is_dbi;
-    my $dbidir = dbd_dbi_dir();
      my %seen;
+    my $dbi_version = '';
+    if($ENV{PERL_CORE}) {
+        ## also if($Config{usecrosscompile}) ? - cant load DBI as built  
for other arch.
+        my $updir = File::Spec->updir;
+        my $CORElibdir = File::Spec->catdir(($updir) x 2, 'lib');
+        my $DBI_pm = File::Spec->catfile($CORElibdir, 'DBI.pm');
+        my $autoDBIdir = File::Spec->catdir($CORElibdir, 'auto', 'DBI');
+        if(!-d $autoDBIdir) {
+            die "Running under PERL_CORE, can't find $autoDBIdir";
+        }
+        $dbi_version = ExtUtils::MM_Unix->parse_version($DBI_pm);
+    } else {
+        $dbi_version = $DBI::VERSION;
+    }
      my @try = grep { not $seen{$_}++ } map { vmsify( unixify($_) .  
"/auto/DBI/" ) } @INC;
      my @xst = grep { -f vmsify( unixify($_) . "/Driver.xst" ) } @try;
      Carp::croak("Unable to locate Driver.xst in @try") unless @xst;
      Carp::carp( "Multiple copies of Driver.xst found in: @xst") if @xst >  
1;
-    print "Using DBI $DBI::VERSION (for perl $] on $Config{archname})  
installed in $xst[0]\n";
+    print "Using DBI $dbi_version (for perl $] on $Config{archname})  
installed in $xst[0]\n";
      return File::Spec->canonpath($xst[0]);
  }


diff -ru ./Makefile.PL  
/usr/src/perl/perl-cross-compile/repo/perl/cpan/DBX-SQLite/Makefile.PL
--- ./Makefile.PL	2012-06-09 15:35:51.000000000 +0100
+++  
/usr/src/perl/perl-cross-compile/repo/perl/cpan/DBX-SQLite/Makefile.PL	2012-12-18  
11:40:22.000000000 +0000
@@ -51,12 +51,29 @@
  # Because DBI generates a postamble at configure-time, we need
  # the required version of DBI very early.
  my $DBI_required = 1.57;
-eval {
-	require DBI;
-};
-if ( $@ or DBI->VERSION < $DBI_required ) {
-	print "DBI 1.57 is required to configure this module; please install it  
or upgrade your CPAN/CPANPLUS shell.\n";
-	exit(0);
+unless($ENV{PERL_CORE}) {
+    $ENV{PERL_CORE} = 1 if grep { $_ eq 'PERL_CORE=1' } @ARGV;
+}
+my $dbi_version = '';
+if($ENV{PERL_CORE}) {
+    ## Avoid actually loading DBI, as we might be cross-compiling
+    my $updir = File::Spec->updir;
+    my $CORElibdir = File::Spec->catdir(($updir) x 2, 'lib');
+    my $DBI_pm = File::Spec->catfile($CORElibdir, 'DBI.pm');
+    if(!-e $DBI_pm) {
+        die "Building under PERL_CORE, but $DBI_pm doesn't exist";
+    }
+    $dbi_version = ExtUtils::MM_Unix->parse_version($DBI_pm);
+} else {
+    eval {
+        require DBI;
+    };
+    $dbi_version = DBI->VERSION;
+
+}
+if ( $@ or $dbi_version < $DBI_required ) {
+    print "DBI 1.57 is required to configure this module; please install  
it or upgrade your CPAN/CPANPLUS shell.\n";
+    exit(0);
  }

  # See if we have a C compiler
@@ -356,7 +373,6 @@
  use Config;

  sub postamble {
-	require DBI;
  	require DBI::DBD;
  	my $postamble = eval {
  		DBI::DBD::dbd_postamble(@_)


Looking at the above I've just realised I failed to change actual finding  
of Driver.xst somewhere other than @INC, no wonder I had issues with the  
actual building... I'll go fix that now!

Summary
-------

0:30h - Admin (writing up)
2:00h - Compiling and testing RunPerl with Object-Remote-Java
2:00h - Gitifying and documenting RunPerl
3:00h - Cross-compiling DBI and DBD::SQLite

Total: 7:30h

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About