«

I'd like to put a Perl script using Inline::C on a shared filesystem.
Users might invoke the script from Linux or Solaris systems.

Now the problem is, the Inline module will use an MD5 digest and caching
to ensure that the C part is recompiled if changed. However, that also
means that the the mechanism won't detect that the script is being
invoked under different operating systems, so it will erroneously
attempt to use the Linux shared lib on Solaris or vice versa.

How can I avoid that in an elegant manner?


Thanks,

Andrei

"Andrei Alexandrescu (See Website For Email)"
<> wrote in message
news:...
> I'd like to put a Perl script using Inline::C on a shared filesystem.
> Users might invoke the script from Linux or Solaris systems.
>
> Now the problem is, the Inline module will use an MD5 digest and caching
> to ensure that the C part is recompiled if changed. However, that also
> means that the the mechanism won't detect that the script is being
> invoked under different operating systems, so it will erroneously
> attempt to use the Linux shared lib on Solaris or vice versa.
>
> How can I avoid that in an elegant manner?
>

I can't think of a very elegant solution. I would create 2 versions of the
Inline::C script - one named 'linux_version.pl', the other named
'solaris_version.pl'. The user would not invoke either of those 2 scripts
directly - instead the user would run a script that looks something lke
this:

use warnings;
if($^O =~ /linux/i) { do 'linux_version.pl'}
else {do 'solaris_version.pl'}

Cheers,
Rob

Andrei Alexandrescu (See Website For Email) wrote:
> I'd like to put a Perl script using Inline::C on a shared filesystem.
> Users might invoke the script from Linux or Solaris systems.
>
> Now the problem is, the Inline module will use an MD5 digest and caching
> to ensure that the C part is recompiled if changed. However, that also
> means that the the mechanism won't detect that the script is being
> invoked under different operating systems, so it will erroneously
> attempt to use the Linux shared lib on Solaris or vice versa.
>
> How can I avoid that in an elegant manner?

Untested, but perhaps you could use Inline's NAME config option and
base the value off $^O.

Ed

"Andrei Alexandrescu (See Website For Email)"
<> wrote:
> I'd like to put a Perl script using Inline::C on a shared filesystem.
> Users might invoke the script from Linux or Solaris systems.
>
> Now the problem is, the Inline module will use an MD5 digest and caching
> to ensure that the C part is recompiled if changed. However, that also
> means that the the mechanism won't detect that the script is being
> invoked under different operating systems, so it will erroneously
> attempt to use the Linux shared lib on Solaris or vice versa.
>
> How can I avoid that in an elegant manner?

I wouldn't exactly call it elegant, but....

my $arch_version;
BEGIN {
use Config;
$arch_version = "./_Inline_" .
$Config{'archname'}.'-'.$Config{'version'};
mkdir $arch_version or die $! unless -d $arch_version;
};

use Inline C=> 'DATA', DIRECTORY => $arch_version;


Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Andrei Alexandrescu (See Website For Email) wrote:

>I'd like to put a Perl script using Inline::C on a shared filesystem.
>Users might invoke the script from Linux or Solaris systems.
>
>Now the problem is, the Inline module will use an MD5 digest and caching
>to ensure that the C part is recompiled if changed. However, that also
>means that the the mechanism won't detect that the script is being
>invoked under different operating systems, so it will erroneously
>attempt to use the Linux shared lib on Solaris or vice versa.
>
>How can I avoid that in an elegant manner?

I think it sounds like a bug in Inline. What it does, is create a
subdirectory ".Inline/lib/auto" and place the compiled module under a
custom sudirectory. What it *should* do, IMO, is place the subdirectory
under ".Inline/lib/$Config{archname}/auto", where %Config is the hash
from Config.pm, or perhaps even throwing in $Config{version} as well.

--
Bart.