PLDelphi is a Perl project hosted on CPAN. I am currently working on a Delphi application and I am investigating the possibility of adding Perl scripting support and read about PLDelphi.
Ideally, I'd like my application to not require Perl to be installed. PLDelphi claims to support this:
To use PLDelphi from your Delphi
application without need to install
Perl you will need this files in the
main diretory of your application:
PLDelphi.dll - The PLDelphi
library that loads the Perl
interpreter. PLDelphi.pm - Perl
side of PLDelphi. Perl56.dll -
The Perl library in case that you have
Perl built dynamic. PLDelphi_dll.pas -
PLDelphi classes and DLL wrapper.
lib/* - A Perl lib directory with basic .pm files (strict, warnings, etc...)
I am aware of RemObjects PascalScript and embedding Python in Delphi, but in this instance, I am interested primarily in Perl support.
Has anyone used PLDelphi with success? Or have you found other ways to execute Perl scripts from Delphi without the full Perl installation available locally?
EDIT:
To be more clear, I found 1 potential solution and that is using PLDelphi. However, I'd like to know if anyone has used it (last updated in 2004) before, and how well it worked.
I'm also interested in hearing about any other options for embedding a Perl interpreter with Delphi.
You could use Windows Script Host (which comes with VBScript and JScript by default) and install PerlScript from ActiveState.
Sadly PLDelphi isn't updated for XE3 or 64 bits there for won't work with Perl 5.16
I was really looking for a solution that didn't require installing anything on the client. It appears that PLDelphi is not working with ActivePerl 5.10...so I don't believe there is a ready solution to embedding Perl within a Delphi application.
Related
I am using Crimson Editor as a text editor and I think it suports only Active Perl as a compiler. I downloaded some new CPAN modules for emailing etc etc. I added them in Perl library but program still doesn't recognize those modules. Can you please help me? Is Active Perl doesn't support any extra modules? If so, what do you suggest me for Perl compiler?
Is Active Perl doesnt support any extra modules?
It does, but it has its own way of doing it called PPM. Because many Perl modules require Unix tools and a C compiler, these are pre-built for you. Unfortunately these packages are often well behind CPAN release and are often missing CPAN modules altogether.
If so, what do you suggest me for Perl compiler?
On Windows, I'd recommend using Strawberry Perl. It comes with a full environment necessary for building and installing Perl modules, including a C compiler. Then you can install things using the normal CPAN tools like cpan or cpanm.
I am using Chrimson Editor
It doesn't look like that editor has been updated in over 10 years, and it's very Windows specific. I'd suggest an editor like Sublime Text. It's cross-platform, so you're not stuck with a Windows-specific editor, it has good Perl support, and it's kept up to date.
I would also not get too attached to relying on your IDE to do all your compiling and running of code for you. If you do, you're limited to what your IDE supports, and your IDE can get in the way of understanding your tools. Instead, I'd suggest getting used to using the tools directly. Learn how to use Perl on the command line rather than via the IDE.
I've written any number of perl modules in the past, and more than a few stand-alone perl programs, but I've never released a multi-file perl program into the wild before.
I have a perl program that is almost at the beta stage and is going to be released open source. It requires a number of data files, as well as some external perl modules -- some I've written myself, and some from CPAN -- that I'll have to bundle with it so as to ensure that someone can just download my program and install it without worrying about hunting for obscure modules.
So, it sounds to me like I need to write an installer to copy all the files to standard locations so that a user can easily install everything. The trouble is, I have no idea what the standard practice would be for this. I have found lots of tutorials on perl module standards, but none on perl program standards.
Does anyone have any pointers to standard paths, installation proceedures, etc, for perl programs? This is going to be complicated by the fact that the program is multi-platform. I've been testing it in Linux, but its designed to work equally well in Windows.
Take a look at PAR and PAR::Packer. You can bundle all of your requirements (even non-Perl requirements) into one file. With PAR::Packer, the user doesn't even need to have Perl installed for it to work.
You might also look at how the various App::* distributions are setup.
The standard installers for modules (ExtUtils::MakeMaker, Module::Build, Module::Install) also work the same way for scripts.
Using such a standard Perl tool will help you to:
distribute your application on the
CPAN (and you'll benefit from
automated tests on various platforms
by CPAN Testers), and so your app
will be installable (with all its dependencies) from the CPAN
shell
help packagers of Linux/BSD distributions to make packages for your product
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.
ActiveState Perl installs an IIS script mapping for the extension .plx. Is this actually used in real life or just something specific to ActiveState?
No, it's not just from ActiveState. O'Reilly's Learning Perl on Win32 systems recommends naming scripts with a .plx extension to disambiguate them from perl modules (with .pm) and non-executable perl libraries (.pl). Nowadays however I'd name anything that is going to be directly run as .pl.
This is a matter of personal preference. It is not something unique to ActiveState. PLX stands for Perl Executable Script which is perhaps a bit more defined then PL which stands for Perl Script (apparently originally Perl Library as another user wrote). However, on CPAN you see numerous places where PLX is used as extension so it is perhaps not so rare as it seems:
On CPAN acx.plx
kobesearch.cpan.org on SerialPort
tag.plx on CPAN
etc.
UPDATE: here's an earlier discussion of the same discussing whether *.pl or *.plx should be used. It also mentions that Prolog uses *.pl as well and playlist is yet another use.
Google shows some matches and there are quite a few of them on CPAN. In fact, originally, .pl stood for 'Perl library'.
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.