Inline::C and multiple platforms

  • Thread starter Andrei Alexandrescu (See Website For Email)
  • Start date
A

Andrei Alexandrescu (See Website For Email)

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
 
S

Sisyphus

"Andrei Alexandrescu (See Website For Email)"
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
 
E

ednotover

Andrei said:
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
 
X

xhoster

"Andrei Alexandrescu (See Website For Email)"
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
 
B

Bart Lateur

Andrei said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top