in reply to Application Distribution (modules, cpan, etc)

I maintain a perl application - rsnapshot - which works on a vast number of platforms. Off the top of my head, I know we have users on Linux, *BSD, OS X, Solaris, Irix, HPUX and AIX, and I expect there's a few others too.

Our standard distribution is a tarball. We then use autoconf and make. Autoconf may be an utter swine, but it works, although if it had been my project from the start we'd use something else - probably a small perl script. Now, we deliberately avoid all third-party modules precisely because of problems that real users (as opposed to perl people) have with getting them to work. If we were to ever rely on someone elses module, we'd bundle it in the tarball, and install in a private .../lib directory.

I would consider PAR, except that from the docs it seems that I'd need to create a PAR package for each platform, on that platform. That, and PAR doesn't install on one of my main development machines.

Replies are listed 'Best First'.
Re^2: Application Distribution (modules, cpan, etc)
by tsee (Curate) on Feb 20, 2007 at 10:31 UTC

    Come on, give me a break. Would you expect to be able to use a DBI which you compiled on linux/x64 to work on Windows/32bit? I don't think so.

    Short of cross-compiling all module dependencies (forget I even said that), there is no way to get any C application to work on a foreign platform. XS modules fall into that category.

    That said, you can build a .par archive of all pure-perl dependencies and that package will work on any platform.

    If your application does not have non-core XS dependencies, you can even use pp's -P option to create a portable perl script with all non-core dependencies embedded. It should subsequently be runnable with a stock perl.

    Additionally, if you build an ELF executable using pp on linux/32, it should work whereever 32bit ELF executables do. By the way: I tried making a binary from rsnapshot. It took about 30 seconds including the download. Of course, I already had PAR::Packer installed.

    As for PAR not installing on your dev machine: Please write to the PAR mailing list about that. We're committed to make PAR work on almost any system.

    Steffen

[reply]

      cross-compiling all module dependencies (forget I even said that), there is no way to get any C application to work on a foreign platform. XS modules fall into that category.

      This is partially false. While I don't believe it's reasonable or worth the time to cross-compile perl modules, as I think you'd end up arguing with Module::Build and ExtUtils::MakeMaker more than anything else — it is possible to reliably cross-compile all sorts of things. I used to maintain a 3d bumpercars type game (with spaceships) that was never finished (of course) that pulled in SDL/GL and various other things and compiled for ELF and win32 from a single platform.

      Should you choose to do so, you'll find tons of documentation and support for cross compiling under many platforms.

      -Paul

[reply]
      Come on, give me a break. Would you expect to be able to use a DBI which you compiled on linux/x64 to work on Windows/32bit? I don't think so.
      Which was, in fact, my point. PAR doesn't help. Additionally, it isn't obvious how to use PAR to do things like install an example configuration file in /etc.

      autoconf and tar, on the other hand, do help.

      And the problem with PAR not installing - this is a bog-standard Debian box, with compilers and whatnot. I can't be bothered with subscribing to a mailing list just to report a bug on what is probably the most common platform, especially when it's a bug in software that isn't even particularly useful to me.

[reply]

In Section Seekers of Perl Wisdom