Hi Ryan, thanks a lot for your fast response (see a copy at the bottom of this message for convenience)!
But how would I then test both module versions (Date::Calc and Date::Pcalc)
with the same test suite, without duplicating code?
And how would I rely on the Perl version in the C/XS version "if something
goes wrong"?
Something along these lines?
package Date::Calc;
BEGIN { eval { require bytes; }; }
use strict;
use vars qw(@ISA @EXPORT @EXPORT_OK %EXPORT_TAGS $VERSION);
@ISA = qw(Exporter DynaLoader);
@EXPORT = qw();
@EXPORT_OK = qw( ... );
%EXPORT_TAGS = (all => [...@export_ok]);
$VERSION = '6.1';
BEGIN # otherwise this comes too late for imports from this module
{
require Exporter;
require DynaLoader;
eval { bootstrap Date::Calc $VERSION; };
if ($@)
{
local($^W) = 0; # avoid "subroutine redefined" warnings for the three
subroutines below
eval { require Date::Pcalc; Date::Pcalc->import(':all'); };
if ($@) { die "Can't find neither the dynamically loadable library
for Date::Calc nor its pure-Perl substitute Date::Pcalc!\n"; }
else { warn "Unable to find the dynamically loadable library for
Date::Calc, falling back to its pure-Perl substitute Date::Pcalc!\n"; }
}
}
sub Decode_Date_EU2
{
...
Another thing I am wondering about:
You wrote: "if something changes later on the module will always continue to
work"
I am wondering _what_ could change later (or "go wrong"), and if it would be
the right thing to do to (silently?) fall back to the pure-Perl version -
maybe even without a warning to the user.
If the Calc.dll (or shared library Calc.so) disappears, this almost
certainly indicates that there is something seriously wrong, which should be
cried about loud and fixed before continuing.
Or if somebody installs a newer Perl version over an existing one, this
could break binary compatibiliy. But I wonder if the "eval bootstrap" above
would be able to catch that.
Anyway:
In the meantime, I found a way how to detect the compiler in Inline.pm. See
the attached Makefile.PL to see how this would work with Date::Calc.
I am reluctant to install the Perl version no matter what, as you suggested;
I'd rather have the user decide what he/she wants, as in this attached file.
Any opinions on all this, anyone?
Cheers,
Steffen
2009/10/13 Ryan Voots <simcop2...@yahoo.com>
> On Tuesday 13 October 2009 06:17:47 O. STeffen BEYer wrote:
> > Dear Perl module authors,
> >
> > what would be the best way to detect whether a working C compiler is
> > available at build time of a module (i.e., in Makefile.PL)?
> >
> > I would like to install a (faster) XS version of a module if that is
> the
> > case, and a (slower) pure-Perl implementation if not.
> >
> > Remember that C compilers are not always available on all systems.
> > Sometimes they cost heavy extra money, or sometimes you have to work
> > with what's there on a customer's or provider's server (where frequently
> > installing a C compiler is not an option due to company policies).
>
> While I've got no idea about detecting the compiler, I would suggest though
> installing the pure perl one no matter what, under a different name and
> having
> the module fall back on it if possible, that way if something changes later
> on
> the module will always continue to work. This could also simplify the
> build
> and install process since you wouldn't have to decide which one to copy
> during
> make install.
>
>
Makefile.PL
Description: Binary data
