How can I check if a binary dependency is available in Perl? - perl

Having volunteered to maintain a stagnant CPAN package (GnuPG) I'd like improve the install files such that they exit gracefully if the gpg binary (which GnuPG is a wrapper for) cannot be found. After a bit of seeking inspiration from other packages, I've come up with adding this to Makefile.PL:
my #paths = grep { -x "$_/gpg" } split /:/, $ENV{PATH}, $ENV{PGP_PATH};
unless ( scalar #paths ) {
print <<EOD;
I can't find the gpg binary on your system. If it's not installed in your usual PATH, set $ENV{PGP_PATH} to include where it can be found and try installing again.
EOD
exit(0);
}
WriteMakefile(
'NAME' => 'GnuPG',
'VERSION_FROM' => 'GnuPG.pm',
'EXE_FILES' => [ gpgmailtunl ],
'LICENSE' => 'GPL',
'LIBS' => [ #paths ],
);
Does that look sane?

If you're using Module::Install or part of that family, you can use do
requires_external_bin 'gpg';
See Module::Install::External for details.
No good reason to reinvent the wheel.

The general concept is fine - if what you need to work is not present, don't create the makefile. The CPAN Testers have rules about exiting with a zero status on failure (which annoys me a lot, but never mind; I hate failing with a success status!).
Question: do you keep a record of where PGP was found at install time, so that if somebody else uses the Perl module without the location on their path, the module can still run?
For DBD::Informix, I have rigid dependencies without which the module cannot be compiled; the Makefile.PL is a major production in its own right because of that. It also tries to handle versions of the software covering over 15 years; that complicates its life, too. If the pre-requisites (some Perl modules; some non-Perl software) is not available, it won't install.

Wouldn't it make more sense to just print a warning? Is gpg necessary for the installation itself?
The code itself looks fine by me. But perhaps there's a built-in 'which' functionality. :).

For better accuracy you should look at File::Which or at least use File::Spec->path().

File::Which would be a crossplatform solution. You will need to either bundle it into inc/ directory or require it to be installed with configure_requires. For EU::MM it can be done with
META_MERGE => {
configure_requires => {
'File::Which' => 0,
Module::Install is also a good solution, but you will need to release new version of distribution each time new version of Module::Install is released and changes are important.

Related

Installing additional files at install time with ExtUtils::MakeMaker/Dist::Zilla (dzil)

tl;dr I want to ship a package.json with my Perl library, run yarn install (or npm install during the installation) and install the downloaded JavaScript dependencies with the Perl modules.
I have the following dist.ini:
name = Foobar
version = 1.2.3
license = Perl_5
copyright_holder = Yours Truly
copyright_year = 2018
[#Filter]
-bundle = #Basic
-remove = GatherDir
[Git::GatherDir]
[Web::FileHeader]
header_filename = EMM-include.pm
file_match = ^Makefile\.PL$
The file EMM-include.pm contains a MY::postamble method:
package MY;
use strict;
use Cwd qw(abs_path);
use File::Spec;
sub postamble {
my ($self) = #_;
my $here = Cwd::abs_path();
my $libdir = File::Spec->catdir($here, 'lib', 'Foobar');
chdir $libdir or die;
0 == system 'yarn', 'install' or die;
chdir $here or die;
return '';
}
The plug-in [Web::FileHeader] takes the file and patches it to the beginning of Makefile.PL.
Then there is a lib/Foobar/package.json:
{
"name": "foobar",
"version": "1.2.3",
"main": "index.js",
"dependencies": {
"ajv": "^6.5.4"
}
}
The MY::postamble section from EMM-include.pm invokes yarn install (replace it with npm install if you don't have yarn) and populate the directory lib/Foobar/node_modules with ajv and its dependencies.
Finally, there must be a module lib/Foobar.pm:
package Foobar;
# ABSTRACT: Just a test.
1;
That almost works as intended: The distribution can be created with dzil build. In the distribution directory, perl Makefile.PL invokes yarn install, the directory lib/Foobar/node_modules gets populated but the files in there are not installed with make install.
If I run perl Makefile.PL a second time, everything works, the JavaScript dependencies make it into blib/ and make install would install the JavaScript modules alongside the Perl modules.
Shipping the JavaScript dependencies with the distribution is not an option. They are already too many and they may have conflicting licenses (I am using GPLv3 here). Downloading the deps at runtime, after the installation will mostly fail because of missing privileges.
True, this has not that much to do with Dist::Zilla, it's rather a problem with ExtUtils::MakeMaker. But I am actually using Dist::Zilla here.
In case it matters, the real distribution is https://github.com/gflohr/qgoda and the last commit at the time of this writing is https://github.com/gflohr/qgoda/commit/3f34a3dfec8da665061432c3a8f7bd8eef28b95e.
First, instead of using [Web::FileHeader] to alter your Makefile.PL, replace [MakeMaker] (used by #Basic) with [MakeMaker::Awesome], which allows you to modify Makefile.PL directly, and correctly enables dynamic_config since your distribution needs it. Also, don't give your include-file a .pm extension since it's not a perl module, and exclude it from being gathered into the resulting distribution so it doesn't accidentally get installed.
[#Filter]
-bundle = #Basic
-remove = GatherDir
-remove = MakeMaker
[Git::GatherDir]
exclude_filename = EMM-include
[MakeMaker::Awesome]
header_file = EMM-include
I strongly suggest using my #Starter bundle instead of the outdated #Basic, but if not at least add [MetaJSON] so you have modern metadata.
[#Starter::Git]
revision = 3
installer = MakeMaker::Awesome
Git::GatherDir.exclude_filename[] = EMM-include
MakeMaker::Awesome.header_file = EMM-include
Regarding what needs to be done at install time. First I will caution that requiring an internet connection to install is not something you can always rely on, nor is having yarn available of course. But the Alien series of modules for installing external libraries does this sort of thing often. Since you don't need to compile this code you probably don't need the whole Alien::Build/Alien::Base setup, but it may turn out to be an easier way to solve your problem than Makefile hacking described below. Basically you would first release an Alien distribution which installs your javascript library if necessary, and then this distribution could depend on that to load the library. If you decide to pursue this direction, check out Alien::Build, and the IRC channel #native on irc.perl.org.
The postamble section for ExtUtils::MakeMaker is not for running arbitrary code; it's for adding custom rules to the Makefile it generates; this is the way you need to influence the make process. I know very little about Makefiles so I can't help you further here, all I can suggest is to read all of the EUMM docs and note that the postamble is a function from MM_Any which you override to add your text, among other options from MM_Any and MM_Unix. You may be able to find people to help you in this direction on the IRC channel #toolchain on irc.perl.org.

Perl undefined yp_get_default_domain detected by DynaLoader.pm when using ARSperl, yet library exists

I have a Ubuntu server that recently pushed a Perl update to 5.14.2 when I installed cpanminus. This broke compatibility with the BMC Remedy API module. It looks like I can't roll back to the old version of Perl, so I've tried recompiling ARSperl for Perl 5.14.2.
The problem is, when I run an old Perl script that used the old module, I get the following:
Can't load '/usr/local/lib/perl5/5.14.2/auto/ARS/ARS.so' for module ARS:
/usr/local/lib/perl5/5.14.2/auto/ARS/ARS.so: undefined symbol:
yp_get_default_domain at /usr/local/lib/perl5/5.14.2/i686-linux/DynaLoader.pm line 190.
So, a bit of Googling tells me that yp_get_default_domain lives in libnsl. I've gone so far as to try recompiling both the ARSperl module and Perl itself with "-lnsl" explicitly called out in the Makefile. Unfortunately, this has gotten me nowhere. The library is indeed installed on the system under /usr/lib/i386-linux-gnu/.
In ARSperl Makefile:
LDFLAGS = -fstack-protector -L/usr/local/lib -L/usr/lib -L/usr/lib/i386-linux-gnu -lnsl
My question is therefore two-fold for the Perl gurus out there.
-How can I determine which of Perl, DynaLoader, or the ARS.so itself can't find "yp_get_default_domain"?
-What is the best next step to troubleshoot the above DynaLoader message for a missing library that is actually present on the system and linked in the module?
Thank you in advance for sharing your knowledge and advice.
Add the directory where library is installed to the $ARS_LDPATH in Makefile.PL
Something like
$ARSAPI = "C:\\ARS_Library\\api764win";
if( $WINDOWS ){
$ARS_LDPATH = qq{-L"$ARSAPI/lib"};
$INCLUDES = qq{-I"$ARSAPI/include"};
}else{
$ARS_LDPATH = "-L$ARSAPI/lib";
$INCLUDES = "-I$ARSAPI/include";
}
We updated to ARSperl 1.93, started using AR API version 6.3 rather than 5.1.2 and added "-lsnl" to the ARSperl Makefile.PL $ARS_LIBS in the section for 6.3.
That resulted in Perl segfaulting every time the ARS.so module was run. After lots of testing and trying to diagnose why segfaults were occurring, we recompiled a separate instance of Perl-5.14.2 from source under /opt/ and removed the 64int option. Updating the shebang lines on all our Perl scripts that need the ARS module to redirect to the Perl version under /opt seems to have gotten things working again.
Thank you Chankey Pathak for pointing me toward the Makefile.PL, I wouldn't have immediately started looking at changing things there without this advice.

Dependency of Image::Imlib2 on CpanTesters

I get a lot of errors on CpanTesters for my module EBook::MOBI::Image
(It is just some additional stuff for EBook::MOBI. Like this I keep graphics-dependencies from the main module away for those who don't need it anyways).
All tests, except those for GNU/Linux fail:
http://www.cpantesters.org/distro/E/EBook-MOBI-Image.html#EBook-MOBI-Image-0.11
Since I only have GNU/Linux and have some lack of experience in general, I ask for some help here.
The test results seem to indicate, that there is a problem with the dependency of Image::Imlib2
http://www.cpantesters.org/cpan/report/2306795e-99db-11e2-8c80-50d7c5c10595
There it says I should take care, that Image::Imlib2 is in the "Makefile.PL", but it is there as you can see:
https://metacpan.org/source/BORISD/EBook-MOBI-Image-0.11/Makefile.PL#L24
Image::Imlib2 itself does not have this issues. Tests pass all the systems:
http://www.cpantesters.org/distro/I/Image-Imlib2.html#Image-Imlib2-2.03
Can somebody give a hint here what is wrong?
The code is hosted here:
https://github.com/borisdaeppen/EBook-MOBI-Image
Thanks a lot.
When I try to install this module (on Cygwin) with the cpan command:
cpan recognizes that I need the Image::Imlib2 module (warning: prerequisite Image::Imlib2 0 not found)
cpan downloads and attempt to build Image::Imlib2
build of Image::Imlib2 fails (you must install the imlib2 library before you can install Image::Imlib2 ... Make has some problems, won't install)
cpan continues to build EBook::MOBI::Image (... Continuing, but chances to succeed are limited)
and of course, the tests for Ebook::MOBI::Image fail
The PREREQ_PM => ... directive in Makefile.PL tell cpan to make an effort to satisfy a prerequisite, but as you see, it will continue the build even if the prerequisite fails to install. The PREREQ_PM directive is good enough for most modules on CPAN, but not for modules that need an external library that cpan can't install on its own.
I think what you want in this case is for the cpan tester to bail out if you can't load the Image::Imlib2 module, and the place to do that is early in Makefile.PL.
if (!eval "require Image::Imlib2") {
print "This distribution requires Image::Imlib2!\n";
exit 0;
}
For systems that can't or won't install Image::Imlib2, bailing out of Makefile.PL will cause the tester to report a result of N/A instead of FAIL.

Can I build Perl modules with ExtUtils::MakeMaker-based build system "out of tree"?

Instead of adding or modifying files in the directory where the sources of a Perl module are unpacked, I would like to build everything in a separate directory. Is this easily achievable with a fairly standard Makefile.PL that uses ExtUtils::MakeMaker? (By easy, I mean something like one or a few command line parameters.) If no, does any of the other build systems support this?
Update / Reason: The Perl module is a binding to a library whose build system is autoconf/automake/libtool-based. The Perl module is shipped together with this library and calling make in the top directory eventually also builds the Perl library. I am interested in building the entire project in a separate build tree. At the moment I do something similar to what runrig suggested, only using symlinks. (cp -sru $(srcdir)/. $(builddir)/.). This has worked so far, but if there is a more elegant solution, I'd like to read about it.
MakeMaker already copies the sources and builds them in a separate directory (that's what blib/ is). You can control the build location with the INST_* set of arguments to WriteMakefile(). This example changes the location from blib/ to foo/.
INST_ARCHLIB => "foo/arch",
INST_LIB => "foo/lib",
INST_BIN => "foo/bin",
INST_SCRIPT => "foo/script",
INST_MAN1DIR => 'foo/man1',
INST_MAN3DIR => 'foo/man3',
In addition you have to tell MakeMaker to cleanup the new build directory.
clean => {
FILES => 'foo'
},
See "Determination of Perl Library and Installation Locations" in the ExtUtils::MakeMaker docs for more info.
cp -R Module-Directory-0.01 Module-Directory-0.01.copy
cd Module-Directory-0.01.copy
perl Makefile.PL
make
make test
...etc.
I ended up using symlinks:
The library to which the Perl module provides bindings uses an
autoconf/automake/libtool-based build system. Makefile.PL is
generated from Makefile.PL.in by configure. Makefile.PL
generates Makefile-pl (Makefile has already been taken by
autoconf/automake).
This is the relevant part of Makefile.am:
all: Makefile-pl src_deps
$(MAKE) -f Makefile-pl
Makefile-pl: Makefile.PL
perl Makefile.PL INSTALLDIRS=$(INSTALLDIRS) PREFIX=$(prefix)
I changed the second target to:
Makefile-pl: Makefile.PL
-[ $(srcdir) != $(builddir) ] && cp -rsu $(abs_srcdir)/. $(builddir)/.
perl Makefile.PL INSTALLDIRS=$(INSTALLDIRS) PREFIX=$(prefix)
This should work as long as building or installing the Perl module
does not result in any files being modified in-place.

How can I tell Module::Build not to add the lib/perl5 subdirectories to the installation path?

I am trying to setup a directory that contains Perl modules that should be set aside to not interfere with a production system.
This works OK, with modules that use Module::Install. I just specify a "lib" option and all is well. Now I tried and tried and I simply cannot make this happen with Module::Build. For instance, this command:
./Build install --lib /foo
Will install the module in "/foo/share/perl/5.10.0".
How can I get rid off the "share/perl/5.10.0" part?
PS: Yes, I have taken a long look at the documentation and found some promising sections, but I simply must admit that I seem to be too stupid to grok them.
See install_path. It looks like (I haven't tried) you can either put in .modulebuildrc or specify on the command line all of the path options:
./Build install --install_base $CUSTOMPERLSTUFF \
--install_path lib=$CUSTOMPERLSTUFF/lib \
--install_path arch=$CUSTOMPERLSTUFF/lib
I think your best chance is with install_base. From the doc:
install_base
You can also set the whole bunch of installation paths by supplying the install_base parameter to point to a directory on your system. For instance, if you set install_base to "/home/ken" on a Linux system, you'll install as follows:
lib => /home/ken/lib/perl5
arch => /home/ken/lib/perl5/i386-linux
script => /home/ken/bin
bin => /home/ken/bin
bindoc => /home/ken/man/man1
libdoc => /home/ken/man/man3
binhtml => /home/ken/html
libhtml => /home/ken/html