People also often ask "How can I compile Perl?" while what they really want is to create an executable that can run on machines even if they don't have Perl installed.
There are several solutions, I know of:
perl2exe of IndigoStar
It is commercial. I never tried. Its web site says it can cross compile Win32, Linux, and Solaris.
Perl Dev Kit from ActiveState.
It is commercial. I used it several years ago on Windows and it worked well for my needs. According to its web site it works on Windows, Mac OS X, Linux, Solaris, AIX and HP-UX.
PAR or rather PAR::Packer that is free and open source. Based on the test reports it works on the Windows, Mac OS X, Linux, NetBSD and Solaris but theoretically it should work on other UNIX systems as well.
Recently I have started to use PAR for packaging on Linux and will use it on Windows as well.
Other recommended solutions?
In addition to the three tools listed in the question, there's another one called Cava Packager written by Mark Dootson, who has also contributed to PAR in the past. It only runs under Windows, has a nice Wx GUI and works differently from the typical three contenders in that it assembles all Perl dependencies in a source / lib directory instead of creating a single archive containing everything. There's a free version, but it's not Open Source. I haven't used this except for testing.
As for PAR, it's really a toolkit. It comes with a packaging tool which does the dependency scanning and assembly of stand-alone executables, but it can also be used to generate and use so-called .par files, in analogy to Java's JARs. It also comes with client and server for automatically loading missing packages over the network, etc. The slides of my PAR talk at YAPC::EU 2008 go into more details on this.
There's also an active mailing list: par at perl dot org.
It is some time since this question was first asked, but Cava Packager can currently produce executable packages for Windows, Linux and Mac OS X. It is no longer Windows only.
Note: As indicated by my name, I am affiliated with Cava Packager.
I'm a Perl newbie and I just downloaded Cava Packager and that's the only one I found working. I've tried ActiveState 5.10.1005 and Strawberry Perl with PAR-Packager on Windows XP.
pp just hangs in mid-stream and no executables created.
Cava provides the only solution to creating exe on Windows so far. Thks.
You could use the perlcc tool that's shipped with most distributions of Perl. I've also found both perl2exe and Active State's Perl Dev kit useful for shipping Perl applications.
Related
I develop and maintain a bioinformatics application suite of 50+ scripts and its deployment process is a mess:
Entire suite is in one big git repository. It has lots of CPAN dependencies, and dozens of internal modules as well.
Development platform is Linux.
Deployment platforms are Windows (20+ users), Mac (10+), Linux (2-3). Most are not 'power users'.
For windows, I have one installer (made with NSIS) for strawberry perl + required modules (ie, I installed strawberry on a windows box, installed all modules and zipped c:\strawberry), and another installer for the suite-- I did this b/c the suite is updated a lot more than the list of required modules.
For Mac, I bundle perl 5.14, all required cpan modules, and the application suite into a double-clickable installer. I don't use the system perl b/c it tends to be out of date. I bundle everything together unlike on windows b/c I suck at mac.
For Linux, I handle their installations manually since there are only a few of them, and they use different distros.
This is obviously a mess that grew organically over several generation of developers. Ideally I would like to create cpan-installable distributions out of the internal libraries and various groups of related scripts, and use module dependencies to let cpan install them for me.
But I'm not sure what the best approach for this is, b/c I'd still need distribute perl itself, would have to write some sort of non-command-line interface to CPAN, control the exact versions of 3rd party CPAN modules, point it by default to my "DarkPan" where I would store our modules, how I would push updates, etc. etc.
I don't think I can use PerlApp or Par since afaik those are for bundling single scripts, not an entire suite of them.
Any advice highly appreciated.
Besides the 3 platforms mentioned (more, if you count the Linux variants), you really have a couple different problems:
Deployment of a standard known-good Perl executable and libraries (CPAN modules).
Deployment of your Perl scripts and modules.
Once upon a time, I supported a large Solaris Perl installation. I tried for a while to stand up a Linux Perl installation "side-by-side", re-using the same CPAN modules. Didn't work. The big problem for me is that a fair number of Perl modules require compilation, which means they target a specific platform. I ended up just with 2 installs, and always remembered to install a new CPAN module in both areas.
We're now 100% Windows, so I don't have the same issue. However, we do run Perl off a shared network drive. All the users map this drive, and run a Registry script that associates .PL files with the network install of Perl. (See my answer to this other Perl question.)
So, besides the mapped drive and the Registry script, users don't need to install anything. Even the CPAN modules are picked up from the network. This solves item #1 (for Windows only users).
Same thing holds true for item #2: the scripts are stored on a network drive (same one) and the users run another Registry script to include the scripts folder in their search PATH. We edit our scripts in one area, and have a "Check-In 'n Release" ("CINR") that we use to, well, check-in and release scripts to the area the users point to. The users can double-click the scripts in Explorer, run them in DOS, or even better yet get them included in the contextual-menu in Explorer, etc. (Actually, we use a .NET application to map the drive and make all these settings for the user, but it can be done much simpler.)
So, how does this help with the other platforms, Linux and Mac? As I ran into with my Solaris/Linux experiment, I think you're stuck with different Perl installation for all 3 platforms, although you should be able to reach the same network drive for your Perl scripts and modules.
The Perl installation might even be OK on a network drive for the Linux users. It's probably easier for them than the Windows users. Mac users are tough. I administer a home Mac network, and I think network drives are very difficult to do in Mac OS X compared to other OSes. It should be as easy as in Linux since so much is the same, but there are very strange problems (for me) mapping NFS and SMB drives. AFP drives are a little easier for the user to map manually, but not so easy to map programmatically.
My Mac recommendation is to try using Platypus. It's definitely great at bundling scripts into a double-clickable application, although your interface options are limited to output only (no user input allowed during execution that I can tell). Not sure if you could put an entire Perl installation into the Platypus app or not, but if you could the paths figured out, you might be able to.
Good luck!
You may wish to check out CAVA packager. It can deal with multiple scripts in a single package.
cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.
This is probably a multi-part question. Background: we have a native (c++) library that is part of our application and we have managed to use SWIG to generate a perl wrapper for this library. We'd now like to distribute this perl module as part of our application.
My first question - how should I distribute this module? Is there a standard way to package pre-built perl modules? I know there is ppm for the ActiveState distro, but I also need to distribute this for linux systems. I'm not even sure what files are required to distribute, but I'm guessing it's the pm and so files, at a minimum.
My next question - it looks like I might need to build my module project for each version of perl that I want to support. How do I know which perl versions I should build for? Are there any standard guidelines... or better yet, a way to build a package that will work with multiple versions of perl?
Sorry if my questions make no sense - I'm fairly new to the compiled module aspects of perl.
CLARIFICATION: the underlying compiled source is proprietary (closed source), so I can't just ship source code and the appropriate make artifacts for the package. Wish I could, but it's not going to happen in this case. Thus, I need a sane scheme for packaging prebuilt binary files for my module.
I look after DBD::Informix, one of the Perl Database Driver modules that works with the DBI (Perl Database Interface). The underlying libraries used to connect to IBM Informix Dynamic Server (IDS) are proprietary, but the DBD::Informix code itself is not. I distribute that code on CPAN, just the same as any other Perl module. People can download that source, and (provided that they have the Informix ClientSDK installed on their machine - and Perl and DBI and so on), they can build DBD::Informix to work with their installed Perl.
I would strongly counsel that you arrange that your Perl interface code be made available in source form, even though the library that it interfaces to is proprietary. This allows people to install the code with any version of Perl they have - without requiring you to deal with inconsistencies.
If you still want to provide binary support, you are going to have to work out which platforms you want to support, and build the module with the standard version of Perl on each such platform. This gets messy. You need access to an instance of each machine. Granted, virtual machines make this easier, but it is still fiddly and the number of platforms and versions only grows. But you still need to support people who don't use the standard version of Perl on their machine - that's why the Perl wrapper interface needs to be provided in source form.
DISCLAIMER: I have next to no experience creating binary packages that can easily be installed. Therefore, I am making this post CW to make it easier for others to add their advice.
You should make the distribution available in source form so it can be compiled on each system tailored according to the specifics of that system. I really like Module::Build for that purpose.
For ActiveState users on Windows, you probably want to have four or six PPMs based on whether you want to support 5.6. Package both 32-bit and 64-bit versions for each of 5.6, 5.8 and 5.10. Use the version of mingw you can install using ppm to compile the modules to preserve binary compatibility.
Another option is to use PAR::Packer and distribute your application in a PAR archive. In that context, PAR::WebStart might be useful although I have not tried it. I have had success with PAR archives in the past, though.
I have a .pl file and I want to execute that file in any system even though perl is not installed. How can I achieve it?
What would be some good examples to do that?
pp can create an executable that includes perl and your script (and any module dependencies), but it will be specific to your architecture, so you couldn't run it on both Windows and linux for instance.
From its doc:
To make a stand-alone executable, suitable for running on a machine that doesn't have perl installed:
% pp -o packed.exe source.pl # makes packed.exe
# Now, deploy 'packed.exe' to target machine...
$ packed.exe # run it
(% and $ there are command prompts on different machines).
Install PAR::Packer. Example for *nix:
sudo cpan -i PAR::Packer
For Strawberry Perl for Windows or for ActivePerl and MSVC installed:
cpan -i PAR::Packer
Pack it with pp. It will create an executable named "example" or "example.exe" on Windows.
pp -o example example.pl
This would work only on the OS where it was built.
P.S. It is really hard to find a Unix clone without Perl. Did you mean Windows?
From perlfaq3's answer to How can I compile my Perl program into byte code or C?:
(contributed by brian d foy)
In general, you can't do this. There are some things that may work for your situation though. People usually ask this question because they want to distribute their works without giving away the source code, and most solutions trade disk space for convenience. You probably won't see much of a speed increase either, since most solutions simply bundle a Perl interpreter in the final product (but see How can I make my Perl program run faster?).
The Perl Archive Toolkit ( http://par.perl.org/ ) is Perl's analog to Java's JAR. It's freely available and on CPAN ( http://search.cpan.org/dist/PAR/ ).
There are also some commercial products that may work for you, although you have to buy a license for them.
The Perl Dev Kit ( http://www.activestate.com/Products/Perl_Dev_Kit/ ) from ActiveState can "Turn your Perl programs into ready-to-run executables for HP-UX, Linux, Solaris and Windows."
Perl2Exe ( http://www.indigostar.com/perl2exe.htm ) is a command line program for converting perl scripts to executable files. It targets both Windows and unix platforms.
Look at PAR (Perl Archiving Toolkit).
PAR is a Cross-Platform Packaging and
Deployment tool, dubbed as a cross
between Java's JAR and
Perl2EXE/PerlApp.
And let's not forget ActiveState's PDK. It will allow you to compile UI, command line, Windows services and installers.
I highly recommend it, it has served me very well over the years, but it is around 300$ for a licence.
Cava Packager is great on the Windows ecosystem.
Perl files are scripts, not executable programs. Therefore, for them to 'run', they are going to need an interpreter.
So, you have two choices:
1) Have the interpreter on the machine that you wish to run the script, or
2) Have the script running on a networked (or Internet) machine that you remotely connect to (ie with a browser)
On Mac OS X there may be perlcc. Type man perlcc. On my system (10.6.8) it's in /usr/bin. Your mileage may vary.
See perl-5.8.9 / perlcc.
I’m using the gcc in MinGW that comes with Strawberry Perl, on Windows XP. I’d like to have ddd (the Data Display Debugger) as well but apparently on Windows the simplest way to get ddd is by running Cygwin. So what's the bare minimum of Cygwin I can install to get ddd up and running? I'd prefer if I could run ddd natively on Win32 but that doesn't seem to be an option.
As far as I can tell so far, only the following (with Cygwin DLL release version 1.5.25-15), and allowing setup to install any other packages to meet dependencies.
Base: base-files, grep
Develop: ddd, gdb
Math: gnuplot
Example to get grep working: Just drop the following files from a cygwin bin directory into an appropriate directory...
cyggcc_s-1.dll
cygiconv-2.dll
cygintl-8.dll
cygpcre-0.dll
cygwin1.dll
grep.exe
The Cygwin setup.exe installer resolves dependencies for you. Just run the installer, find and enable ddd, and click Next. It might install some packages you doun't strictly need, but figuring out which ones you can safely omit is probably a waste of time.
Disclaimer: I haven't tried this; I just install eveything.
If you're going for minimalism, you might want a smaller X server than cygwin-x11 (though it's what I use, and I'm quite fond of it). Starwin X-Win32 is actively maintained (though it costs $$ beyond the trial period), and avoids the overhead of installing Cygwin proper; there are other, zero-cost minimal X servers for win32 available, but I don't have linkage immediately available.
As the documentation at x.cygwin.com indicates, the xorg-x11-base package is the bare minimum needed.