Jesse Thompson tag:blogs.perl.org,2009-11-03:/users/jesse_thompson//389 2011-10-31T16:37:54Z A blog about the Perl programming language Movable Type Pro 4.38 Perl Has No Static Code Analysis Tools? tag:blogs.perl.org,2011:/users/jesse_thompson//389.2377 2011-10-31T16:28:40Z 2011-10-31T16:37:54Z Don't believe what you read on the Internet. Despite what Wikipedia says - Wikipedia's List of tools for static code analysis - Perl has plenty of tools for static code analysis. e.g. Perl::Critic and Perl::Tidy Let's fix this. Anyone a... Jesse Thompson Don't believe what you read on the Internet.

Despite what Wikipedia says - Wikipedia's List of tools for static code analysis - Perl has plenty of tools for static code analysis.

e.g. Perl::Critic and Perl::Tidy

Let's fix this. Anyone a Wikipedia editor?

]]> Perl in the News tag:blogs.perl.org,2011:/users/jesse_thompson//389.1649 2011-04-14T02:59:27Z 2011-04-14T03:03:29Z Perl FTW (open source implementation of Apple AirPort Express) http://www.mafipulation.org/blagoblig/2011/04/08#shairport... Jesse Thompson Perl FTW (open source implementation of Apple AirPort Express)

http://www.mafipulation.org/blagoblig/2011/04/08#shairport

]]> Adding Version Control Sanity to Solaris logadm tag:blogs.perl.org,2011:/users/jesse_thompson//389.1635 2011-04-10T01:36:08Z 2011-04-10T02:59:57Z Solaris includes a log rolling utility called logadm, which is very useful for managing logs without having to write your own custom scripts or install some other utility across all of your servers. However, there is one big drawback... Jesse Thompson Solaris includes a log rolling utility called logadm, which is very useful for managing logs without having to write your own custom scripts or install some other utility across all of your servers.

However, there is one big drawback to logadm. Whenever it runs, it stores a timestamp for each log it rolls in the logadm configuration file itself. I'll leave it to the reader to question the sanity of this.

For example: 

/var/adm/messages -C 4 -a 'kill -HUP `cat /var/run/syslog.pid`'

Is changed to: 

/var/adm/messages -C 4 -P 'Sat Apr 09 21:27:21 2011' -a 'kill -HUP `cat /var/run/syslog.pid`'

My immediate dilemma is that I like to put everthing important into version control. But since the logadm configuration file is constantly modified, it isn't practical to store it in version control without it getting overwritten every time it is deployed to the system from version control.

So, I wrote this simple perl script that takes both files in as arguments and spits out a version of the file that can be safely deployed. There is nothing complex about this script, but I share it here for the benefit of others that run across this dilemma. 

#!/usr/bin/perl

my ($configfile, $systemfile) = @ARGV;

# check input
unless ( $configfile and $systemfile and -f $configfile ) {
    print "usage: $0 configfile systemfile\n";
    exit;
}

# nothing to fix
if ( ! -e $systemfile ) {
    exit;
}

# open each file for reading
open my $systemfile_fh, '<', $systemfile or die "can't open $systemfile: $!";
open my $configfile_fh, '<', $configfile or die "can't open $configfile: $!";

# read in each line of the file that does not have the -P timestamp
while ( my $configfile_line = <$configfile_fh> ) {
    chomp $configfile_line;

    # then read in each line of the file that has the -P timestamp
    while ( my $systemfile_line = <$systemfile_fh> ) {
        chomp $systemfile_line;

        # if the line has the -P timestamp
        if ( $systemfile_line =~ /(.*)(\-P\s+'.*?'\s*)(.*)/ ) {

            # remove the -P timestamp and see if it is identical in both files
            my $systemfile_line_sans = $1.$3;
            my $insert = $2;
            if ( $configfile_line eq $systemfile_line_sans ) {

                # if the lines match then we will want to use the replace the
                # line with the version that has the -P timestamp
                $configfile_line = $systemfile_line;
            }
        }
    }

    # print out each line, whether we have swapped it, or not
    print $configfile_line."\n";
}
close $configfile_fh;
close $systemfile_fh;
]]> Perl-based Massively Multiplayer Online Game tag:blogs.perl.org,2010:/users/jesse_thompson//389.1062 2010-09-30T17:58:22Z 2010-09-30T18:11:42Z JT Smith and his crew have created a massively multiplayer online game called the Lacuna Expanse. The game is great, but the coolest part is that the back-end is written entirely with Perl! JT unveiled the game and the underlying... Jesse Thompson JT Smith and his crew have created a massively multiplayer online game called the Lacuna Expanse. The game is great, but the coolest part is that the back-end is written entirely with Perl!

JT unveiled the game and the underlying technology at the latest Madison Perl Mongers meeting.

]]> CPAN Search Dependents tag:blogs.perl.org,2010:/users/jesse_thompson//389.936 2010-08-23T22:31:25Z 2010-08-24T12:16:58Z When I search CPAN, I frequently find it hard to tell which modules to choose. Unless my needs are very specialized, there can be lots of modules that do what I need. But how would I know which module is... Jesse Thompson When I search CPAN, I frequently find it hard to tell which modules to choose. Unless my needs are very specialized, there can be lots of modules that do what I need. But how would I know which module is best to choose?

One factor that can help me decide is the number of CPAN dependents each module has. (Don't confuse "dependent" with "dependency"; I use the word "dependent" to mean: other modules that depend on it.) If a module has lots of other modules that depend on it, then I can be relatively certain that the module might be worth relying on.

The information about the modules' dependents is exposed by http://deps.cpantesters.org/depended-on-by.pl, which is rather cumbersome to use.

So, I created a greasemonkey script which dynamically shows the number of dependents for each module on the search.cpan.org search results. It then displays the list of distributions in order of their numbers of dependents.

CPAN Search Dependents - is the link to the greasemonkey script.

Here is a screenshot of the script in action.

Note that it works better if you show 100 modules at a time, otherwise you might miss distributions that aren't displayed in the first 10 results.

Showing CPAN dependents is only one small factor in measuring the popularity of a module, and popularity isn't the only factor. Down the road I would like to display other information, such as data from Google search.

]]> Powered by mod_perl tag:blogs.perl.org,2010:/users/jesse_thompson//389.914 2010-08-17T14:24:58Z 2010-08-17T14:35:14Z Here's a quick and easy way for you to subtly advertise your use of mod_perl. Add this to your Apache conf. Header add X-Powered-By mod_perl/2.0 You should be able to add it to any appropriate section or directive. I added... Jesse Thompson Here's a quick and easy way for you to subtly advertise your use of mod_perl.

Add this to your Apache conf.

Header add X-Powered-By mod_perl/2.0

You should be able to add it to any appropriate section or directive. I added it right below "ServerTokens Prod". mod_header documentation

]]> Powered by mod_perl tag:blogs.perl.org,2010:/users/jesse_thompson//389.913 2010-08-17T14:24:58Z 2010-08-17T14:31:02Z Here's a quick and easy way for you to advertise your use of mod_perl. Add this to your Apache conf. Header add X-Powered-By mod_perl/2.0 You should be able to add it to any appropriate section or directive. I added it... Jesse Thompson Here's a quick and easy way for you to advertise your use of mod_perl.

Add this to your Apache conf.


Header add X-Powered-By mod_perl/2.0

You should be able to add it to any appropriate section or directive. I added it right below "ServerTokens Prod".

]]> Perl 12 tag:blogs.perl.org,2010:/users/jesse_thompson//389.795 2010-07-26T18:24:58Z 2010-07-26T20:23:00Z Many people are saying that Perl 5 should be renamed. I disagree. Perl is Perl. That's what makes it great. However, I agree that the 5.x version naming is a burden for people who want to advocate the modern relevance... Jesse Thompson Many people are saying that Perl 5 should be renamed. I disagree. Perl is Perl. That's what makes it great. However, I agree that the 5.x version naming is a burden for people who want to advocate the modern relevance of Perl. So, why don't we just drop the "5."?

Perl 12. The current version of Perl is 12.1. That looks right to me. It just fits. Perl 12.x (and 14.x, etc...) just makes more sense because it conveys that Perl is mature (it is) and it has a healthy schedule of stable major releases (it does.)

This idea is not unprecedented.

Is it Solaris 5 or 10?

  ~> uname -r
  5.10


Is it Java 1 or 6?

  ~> java -version
  java version "1.6.0_16"


I'm sure that there are other examples of this.

Nothing technical has to change. Perl 12.x will still be Perl 5.12.x when you install it on your system just like Java 6 is Java 1.6 and Solaris 10 is Solaris 5.10. Only the marketing and the nomenclature would change.

What about Perl 6? Well, Perl 6 isn't really the next version of Perl 5, right? Perl 6 is a language specification, and Rakudo 1 is an implementation of Perl 6.x. I don't see the Perl 12 nomenclature interfering with Perl 6 or its implementation(s).

]]> cpanm --makepl_args ? tag:blogs.perl.org,2010:/users/jesse_thompson//389.731 2010-07-08T17:02:40Z 2010-07-08T17:25:15Z As a follow-up to one of issues I raised in Installing Deviant OpenSSL XS Modules, I sought out to determine how difficult it would be pass makepl_args (arguments for Makefile.PL) to cpanminus. Here is what I came up with. ---... Jesse Thompson As a follow-up to one of issues I raised in Installing Deviant OpenSSL XS Modules, I sought out to determine how difficult it would be pass makepl_args (arguments for Makefile.PL) to cpanminus.

Here is what I came up with.

--- bin/cpanm.orig	2010-07-08 11:33:53.000000000 -0500
+++ bin/cpanm	2010-07-08 12:24:27.000000000 -0500
@@ -357,6 +357,7 @@
           configure_timeout => 60,
           try_lwp => 1,
           uninstall_shadows => 1,
+          makepl_args => undef,
           @_,
       }, $class;
   }
@@ -400,6 +401,7 @@
           'self-upgrade' => sub { $self->{cmd} = 'install'; $self->{skip_installed} = 1; push @ARGV, 'App::cpanminus' },
           'uninst-shadows!'  => \$self->{uninstall_shadows},
           'lwp!'    => \$self->{try_lwp},
+          'makepl_args=s' => \$self->{makepl_args},
       );
   
       $self->{argv} = \@ARGV;
@@ -547,6 +549,7 @@
     --prompt                  Prompt when configure/build/test fails
     -l,--local-lib            Specify the install base to install modules
     -L,--local-lib-contained  Specify the install base to install all non-core modules
+    --makepl_args             Specify arguments to be given to Makefile.PL
   
   Commands:
     --self-upgrade            upgrades itself
@@ -1326,14 +1329,24 @@
   
       my $try_eumm = sub {
           if (-e 'Makefile.PL') {
-              $self->chat("Running Makefile.PL\n");
+              $self->{makepl_args} ? 
+                  $self->chat("Running Makefile.PL " . $self->{makepl_args} . "\n") : 
+                  $self->chat("Running Makefile.PL\n");
+
               local $ENV{X_MYMETA} = 'YAML';
   
               # NOTE: according to Devel::CheckLib, most XS modules exit
               # with 0 even if header files are missing, to avoid receiving
               # tons of FAIL reports in such cases. So exit code can't be
               # trusted if it went well.
-              if ($self->configure([ $self->{perl}, @switches, "Makefile.PL" ])) {
+              if ($self->configure([ 
+                      $self->{perl}, 
+                      @switches, 
+                      "Makefile.PL", 
+                      $self->{makepl_args} ? 
+                          split /\s+/, $self->{makepl_args} : 
+                          undef 
+              ])) {
                   $state->{configured_ok} = -e 'Makefile';
               }
               $state->{configured}++;

It's a blunt approach, since it will apply the makepl_args for all dependencies, which may or may not be what the user intends. Also, I didn't test how this would impact Module::Build modules.

I submitted the patch to miyagawa to see what he thinks of the idea.

]]> Installing Deviant OpenSSL XS Modules tag:blogs.perl.org,2010:/users/jesse_thompson//389.726 2010-07-07T15:16:34Z 2010-07-08T17:31:40Z Installing XS modules that link to OpenSSL can be tricky if you don't have OpenSSL installed in the normal place. I'm using Solaris 10, and I have OpenSSL installed in /usr/sfw. I was having a problem getting Crypt::OpenSSL::Random, Crypt::OpenSSL::RSA, Crypt::OpenSSL::DSA... Jesse Thompson Installing XS modules that link to OpenSSL can be tricky if you don't have OpenSSL installed in the normal place. I'm using Solaris 10, and I have OpenSSL installed in /usr/sfw.

I was having a problem getting Crypt::OpenSSL::Random, Crypt::OpenSSL::RSA, Crypt::OpenSSL::DSA and Crypt::OpenSSL::Bignum to install.

~> /usr/bin/perl Makefile.PL

Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for -lssl
Note (probably harmless): No library found for -lcrypto
Writing Makefile for Crypt::OpenSSL::Random
~> make
cp Random.pm blib/lib/Crypt/OpenSSL/Random.pm
AutoSplitting blib/lib/Crypt/OpenSSL/Random.pm (blib/lib/auto/Crypt/OpenSSL/Random)
/usr/bin/perl /usr/perl5/site_perl/5.8.4/ExtUtils/xsubpp  -typemap /usr/perl5/5.8.4/lib/ExtUtils/typemap  Random.xs > Random.xsc && mv Random.xsc Random.c
Please specify prototyping behavior for Random.xs (see perlxs manual)
cc -c    -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -xO3 -xspace -xildoff    -DVERSION=\"0.04\"  -DXS_VERSION=\"0.04\" -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"   Random.c
"Random.xs", line 5: cannot find include file: 
"Random.xs", line 23: warning: implicit function declaration: RAND_bytes
"Random.xs", line 25: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h", line 520
        argument : pointer to unsigned char
"Random.xs", line 50: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h", line 520
        argument : pointer to unsigned char
"Random.xs", line 71: warning: implicit function declaration: RAND_seed
"Random.xs", line 72: warning: implicit function declaration: RAND_status
"Random.xs", line 87: warning: implicit function declaration: RAND_egd
cc: acomp failed for Random.c
*** Error code 2
make: Fatal error: Command failed for target `Random.o'


It couldn't compile because it didn't find the OpenSSL header files. I neglected to specify the additional include path, which I can do by specifying an INC argument to Makefile.PL. 

~> /usr/bin/perl Makefile.PL INC=-I/usr/sfw/include

Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for -lssl
Note (probably harmless): No library found for -lcrypto
Writing Makefile for Crypt::OpenSSL::Random
~> make
cp Random.pm blib/lib/Crypt/OpenSSL/Random.pm
AutoSplitting blib/lib/Crypt/OpenSSL/Random.pm (blib/lib/auto/Crypt/OpenSSL/Random)
/usr/bin/perl /usr/perl5/site_perl/5.8.4/ExtUtils/xsubpp  -typemap /usr/perl5/5.8.4/lib/ExtUtils/typemap  Random.xs > Random.xsc && mv Random.xsc Random.c
Please specify prototyping behavior for Random.xs (see perlxs manual)
cc -c  -I/usr/sfw/include  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -xO3 -xspace -xildoff    -DVERSION=\"0.04\"  -DXS_VERSION=\"0.04\" -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"   Random.c
"Random.xs", line 25: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h", line 520
        argument : pointer to unsigned char
"Random.xs", line 50: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h", line 520
        argument : pointer to unsigned char
Running Mkbootstrap for Crypt::OpenSSL::Random ()
chmod 644 Random.bs
rm -f blib/arch/auto/Crypt/OpenSSL/Random/Random.so
cc  -G Random.o  -o blib/arch/auto/Crypt/OpenSSL/Random/Random.so       \
        \
  
chmod 755 blib/arch/auto/Crypt/OpenSSL/Random/Random.so
cp Random.bs blib/arch/auto/Crypt/OpenSSL/Random/Random.bs
chmod 644 blib/arch/auto/Crypt/OpenSSL/Random/Random.bs
Manifying blib/man3/Crypt::OpenSSL::Random.3
> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
1..5
Can't load 'blib/arch/auto/Crypt/OpenSSL/Random/Random.so' for module Crypt::OpenSSL::Random: ld.so.1: perl: fatal: relocation error: file blib/arch/auto/Crypt/OpenSSL/Random/Random.so: symbol RAND_bytes: referenced symbol not found at /usr/perl5/5.8.4/lib/sun4-solaris-64int/DynaLoader.pm line 230.
 at test.pl line 11
Compilation failed in require at test.pl line 11.
BEGIN failed--compilation aborted at test.pl line 11.
not ok 1
*** Error code 255
make: Fatal error: Command failed for target `test_dynamic'


Now it compiles, but failed to link. I neglected to specify the additional lib path, which I can do by passing in a LIBS argument to Makefile.PL.

~> /usr/bin/perl Makefile.PL LIBS=-L/usr/sfw/lib INC=-I/usr/sfw/include

Checking if your kit is complete...
Looks good
Writing Makefile for Crypt::OpenSSL::Random
~> make
cp Random.pm blib/lib/Crypt/OpenSSL/Random.pm
AutoSplitting blib/lib/Crypt/OpenSSL/Random.pm (blib/lib/auto/Crypt/OpenSSL/Random)
/usr/bin/perl /usr/perl5/site_perl/5.8.4/ExtUtils/xsubpp  -typemap /usr/perl5/5.8.4/lib/ExtUtils/typemap  Random.xs > Random.xsc && mv Random.xsc Random.c
Please specify prototyping behavior for Random.xs (see perlxs manual)
cc -c  -I/usr/sfw/include  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -xO3 -xspace -xildoff    -DVERSION=\"0.04\"  -DXS_VERSION=\"0.04\" -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"   Random.c
"Random.xs", line 25: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h", line 520
        argument : pointer to unsigned char
"Random.xs", line 50: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h", line 520
        argument : pointer to unsigned char
Running Mkbootstrap for Crypt::OpenSSL::Random ()
chmod 644 Random.bs
rm -f blib/arch/auto/Crypt/OpenSSL/Random/Random.so
cc  -G Random.o  -o blib/arch/auto/Crypt/OpenSSL/Random/Random.so       \
        \
  
chmod 755 blib/arch/auto/Crypt/OpenSSL/Random/Random.so
cp Random.bs blib/arch/auto/Crypt/OpenSSL/Random/Random.bs
chmod 644 blib/arch/auto/Crypt/OpenSSL/Random/Random.bs
Manifying blib/man3/Crypt::OpenSSL::Random.3
> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
1..5
Can't load 'blib/arch/auto/Crypt/OpenSSL/Random/Random.so' for module Crypt::OpenSSL::Random: ld.so.1: perl: fatal: relocation error: file blib/arch/auto/Crypt/OpenSSL/Random/Random.so: symbol RAND_bytes: referenced symbol not found at /usr/perl5/5.8.4/lib/sun4-solaris-64int/DynaLoader.pm line 230.
 at test.pl line 11
Compilation failed in require at test.pl line 11.
BEGIN failed--compilation aborted at test.pl line 11.
not ok 1
*** Error code 255
make: Fatal error: Command failed for target `test_dynamic'


Weird. Still failing to link. It seems to be ignoring what I pass in to the LIBS argument.

This is where I got stuck. I realized that I didn't know how MakeMaker works. I did some Googling for the error and read the ExtUtils::MakeMaker documentation. Then I found this blog post on
Installing Crypt::OpenSSL::RSA on Solaris 10 which told me what I was doing wrong.

Taking a look at Makefile.PL...

~> less Makefile.PL 

use ExtUtils::MakeMaker;
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
    'NAME'              => 'Crypt::OpenSSL::Random',
    'VERSION_FROM'      => 'Random.pm', # finds $VERSION
    'PREREQ_PM'         => {}, # e.g., Module::Name => 1.1
    'LIBS'              => ['-lssl -lcrypto'],   # e.g., '-lm' 
    'DEFINE'            => '', # e.g., '-DHAVE_SOMETHING'
    'INC'               => '', # e.g., '-I/usr/include/other'
);


LIBS is already defined. What happens when you pass in a LIBS argument to Makefile.PL? It doesn't append it, it overrides it.

The existing value "-lssl -lcrypto" is important, so we don't want to override the value. Also, in the blog post I mentioned, jad noticed that the ordering of the LIBS arguments is important. So, even if MakeMaker was smart enough to append my additions to LIBS, how would it know to pre-pend vs. post-pend.

So, the solution is to combine the completed LIBS arguments to pass in to Makefile.PL.

~> /usr/bin/perl Makefile.PL LIBS="-L/usr/sfw/lib -lssl -lcrypto" INC=-I/usr/sfw/include

Checking if your kit is complete...
Looks good
Writing Makefile for Crypt::OpenSSL::Random
~> make
cp Random.pm blib/lib/Crypt/OpenSSL/Random.pm
AutoSplitting blib/lib/Crypt/OpenSSL/Random.pm (blib/lib/auto/Crypt/OpenSSL/Random)
/usr/bin/perl /usr/perl5/site_perl/5.8.4/ExtUtils/xsubpp  -typemap /usr/perl5/5.8.4/lib/ExtUtils/typemap  Random.xs > Random.xsc && mv Random.xsc Random.c
Please specify prototyping behavior for Random.xs (see perlxs manual)
cc -c  -I/usr/sfw/include  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -xO3 -xspace -xildoff    -DVERSION=\"0.04\"  -DXS_VERSION=\"0.04\" -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"   Random.c
"Random.xs", line 25: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h", line 520
        argument : pointer to unsigned char
"Random.xs", line 50: warning: argument #1 is incompatible with prototype:
        prototype: pointer to const char : "/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE/proto.h", line 520
        argument : pointer to unsigned char
Running Mkbootstrap for Crypt::OpenSSL::Random ()
chmod 644 Random.bs
rm -f blib/arch/auto/Crypt/OpenSSL/Random/Random.so
LD_RUN_PATH="/usr/sfw/lib" cc  -G Random.o  -o blib/arch/auto/Crypt/OpenSSL/Random/Random.so    \
   -L/usr/sfw/lib -lssl -lcrypto        \
  
chmod 755 blib/arch/auto/Crypt/OpenSSL/Random/Random.so
cp Random.bs blib/arch/auto/Crypt/OpenSSL/Random/Random.bs
chmod 644 blib/arch/auto/Crypt/OpenSSL/Random/Random.bs
Manifying blib/man3/Crypt::OpenSSL::Random.3
> make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
1..5
ok 1
ok 2
ok 3
ok 4
ok 5


This method worked for all of the aformentioned modules without fail.

Additional Question

Now I pose the same question as jad. Is there a way to do this when installing modules using cpan or cpanminus?

Update: I pose the possibility of adding a makepl_args option for cpanminus in cpanm --makepl_args ?

]]> Using App::cpanminus and PerlGcc to Install CPAN Modules on Solaris 10 tag:blogs.perl.org,2010:/users/jesse_thompson//389.719 2010-07-06T19:00:08Z 2010-07-07T19:15:03Z If you have had the [dis]pleasure of deploying perl applications on Solaris, you probably have scores of tricks up your sleeve for installing pesky Perl modules. I find it necessary that application installations be scripted so I try to avoid... Jesse Thompson If you have had the [dis]pleasure of deploying perl applications on Solaris, you probably have scores of tricks up your sleeve for installing pesky Perl modules. I find it necessary that application installations be scripted so I try to avoid anything that requires manual intervention.

Some modules on the CPAN will only install if you use gcc. Building CPAN Perl modules on Solaris 10 tells you how to use perlgcc to accomplish this. Pretty neat. I, admittedly, didn't know about perlgcc until today. It sure would have saved me a lot of headache over the years. I don't know how well it covers edge cases, and I'm sure there are pitfalls.

Let's take this a step further and see if we can get the perlgcc technique to work with cpanminus.

I've been loving cpanminus lately for many reasons. It's helped to avoid some of the obscure issues with installing CPAN modules, but mostly because it introduced me to local::lib. local::lib makes it simple to install Perl modules in alternative directories. This is absolutely necessary if you are using Solaris 10 sparse zones, in which you can't write to /usr, but you want to use the system perl.

I needed to install XML::CanonicalizeXML because it was a prerequisite for another module that I needed.

~> sudo /usr/bin/perl cpanm XML::CanonicalizeXML
Building and testing XML-CanonicalizeXML-0.03 for \
XML::CanonicalizeXML ... FAIL


# in build.log

cc: acomp failed for canon.c


This module failed to install when canon.c failed to compile using the Forte CC compiler installed on the server. Feel free to criticize the fact that I didn't (or couldn't) figure out why it failed to compile with the Forte compilers.

UPDATE: I eventually l figured out why XML::CanonicalizeXML didn't compile with Forte compilers. The source code of the C files had end of line characters that Forte CC didn't like. As a result, it was unable to properly parse the multiline macro in canon.c. It compiled after combining the multi-line macro to one line, or by running canon.c through dos2unix.

Taking the lazy way out, let's see what happens when I swap perl with perlgcc.

~> sudo /usr/perl5/bin/perlgcc cpanm XML::CanonicalizeXML
Building and testing XML-CanonicalizeXML-0.03 for \
XML::CanonicalizeXML ... OK


FTW! I now have yet another technique for installing CPAN modules on Solaris. Time will tell if this technique will replace the other hacks that I have been using in the past.

]]> Script vs. Simple Application tag:blogs.perl.org,2010:/users/jesse_thompson//389.671 2010-06-25T17:26:40Z 2010-06-25T17:46:23Z I find myself in the habit of saying that I will write a "script" as opposed to an "application" or a "program." I suppose that my habit of saying "script" has roots in procedural language design. Although I still have... Jesse Thompson I find myself in the habit of saying that I will write a "script" as opposed to an "application" or a "program." I suppose that my habit of saying "script" has roots in procedural language design. Although I still have a habit of saying "script" even if I write an OO application.

Perhaps I unconsciously use the word "script" when I actually mean "simple application" because I want to convey to others that the task will be simple to perform - because I'm leveraging the power of Perl and the CPAN - and will be done quickly.

Perhaps I'm unconsciously thinking that it is risky to say "application" around people who like to over-implement projects (too much planning and hiring of consultants.) On the other hand, it is risky to say "script" around those same people once the development is underway - because they want to be assured that it is being well designed.

Nevertheless, I think that I will try to avoid using the word "script" in most situations.

]]> The face of the CPAN tag:blogs.perl.org,2010:/users/jesse_thompson//389.667 2010-06-24T22:58:35Z 2010-06-25T00:50:41Z One of the things that people were emphasizing at YAPC::NA::2010 was the importance of marketing and framing Perl. Another thing we learned is that the CPAN is the "language" for our Perl "virtual machine." If you were telling a novice... Jesse Thompson One of the things that people were emphasizing at YAPC::NA::2010 was the importance of marketing and framing Perl. Another thing we learned is that the CPAN is the "language" for our Perl "virtual machine."

If you were telling a novice Perl developer about the CPAN, which web site would you send them to?

Perform a Google search for "cpan" and notice that www.cpan.org is returned as the first result. Don't get me wrong, www.cpan.org is a great resource for developers. However, I don't think that it gives a very good first impression. perl.org/cpan.html seems to be an improvement, in my opinion.

What should the face of the CPAN be like?

No one wants to step on any toes. Is www.cpan.org "well volunteered" or "patches welcome" friendly?

Or would we be better off referring and linking to the other faces of the CPAN?

]]>