#!/bin/ksh
# If ksh isn't available for all platforms, use /bin/sh, 
#  but test the the argument quoting below -- not 
#   all /bin/sh are created equal...

# have this be file ~/bin/perl

ARCH=`uname`
exec ~/bin/perl-$ARCH "$@"
[download]

Thanks. So, when I compile it for the other platforms, I should just install it to a temporary directory and copy the binaries over?

This works from the shell, but not in a shebang line. I posted another question about it.

I don't understand the question. Provided you write portable Perl, your program will run anywhere that Perl does. Do you have Perl binaries built for one specific architecture stored on an NFS partition shared across other architectures? If so, it doesn't work that way. Each operating system/hardware platform will need its own version of Perl. In general, you can't run a Perl executable compiled for HP-UX on Solaris. They're source compatible, not binary compatible.

I (currently) have perl binaries built for sgi shared across achitectures. I'm going to compile perl for HP and Linux as well; I'm just trying to determine the best way to go about doing that (all the different binaries in one directory, or entirely different directories for the different platforms). If I have them in separate directories, then I also have to have separate copies of all the modules, man pages, etc.; however, I don't know how much is platform-specific and how much isn't.

Basically, anything that needs to be compiled will have to have its platform specific version. That definitely means the Perl executable itself.

Most modules are straight Perl, however, and run on any platform that has a Perl executable, so you can keep them in a common directory. Some modules have parts of them written in C (usually for speed), that will need compiling. Those modules will need platform-specific versions.

BTW, your idea to have the hash bang line in your scripts refer to a wrapper script that calls the actual platform dependent perl binary is neat, if you can pull it off in a portable way (the one script needs to run on all your platforms - it's an easy way to create a chicken and egg problem).

CU
Robartes-

Hmm.. I'm not sure what all the fuss is about in this thread. It's a pretty simple problem, and almost all of it is handled for you by perl itself...

First you need a directory for each platform to hold its binaries. Personally, I like to hide them:

cd ~/perl
mkdir bin
mkdir .platforms
cd .platforms
mkdir SunOS5.8 Linux2.4.14
cd ..
[download]

Make as many directories as you have architechtures. I suggest using names that are a combination of uname -s and -r output, but whatever scheme you like is fine.

Make a source directory or whatever and put the perl source in it.

mkdir source
cd source
tar xzvf ~/stable.tar.gz        (or wherever it is)
[download]

Now, on each platform simply compile perl as you normally would, with only one change. When asked 'Pathname where the public executables will reside?', answer:

~/perl/.platforms/SunOS5.8      (or whichever platform you're on.)
[download]

Now all the architechture dependent executables, like 'perl' will be installed in that directory. Next, just write a shell script (sh is probably most universal) that does something like this:

#!/bin/sh
system=`uname -s`
release=`uname -r`
exec $HOME/perl/.platform/$system$release/$0 "$@"
[download]

You can obviously make the wrapper much fancier if you like. When you have it how you'd like it, place it in ~/perl/bin and call it .wrapper. Then just create symbolic links for each item in .platform/SunOS5.8 or whatever that point to .wrapper. For example:

cd ~/perl/bin
ln -s .wrapper perl
[download]

Now whenever you execute ~/perl/bin/perl, it will exec the version of perl for your platform. Since the normal perl installation takes care of what to do for architechture specific library files and so on, that should be all you need to do.

When installing perl modules that are pure perl, you should really only have to do it on one platform. For modules that actually compile C code or whatever though, you will probably have to build them on each platform.

The other option, rather than a wrapper, is to simply make sure that the appropriate architecture's bin directory in in your PATH.

Now, I should admit that I haven't done this in quote some time, so your mileage may vary. But in principle, that's all there is to it.

In principle, that's all there is to it. Unfortunatly, it isn't working in practice.