I have a very big Perl module, and I am expecting to call it in my Visual C++ project. I know there are tools like perl2exe and pp that can convert Perl modules to standalone executables (abc.exe).
I don't like the standalone executable because it makes the interface very complex. I have to call the Perl module by creating a process and communicating with it using standard input/output.
It will be much easier if the Perl module is a C/C++ static library. Just link it and call a function!
Thanks in advance!
You can't (yet|easily) compile modules. Instead, embed the Perl interpreter as a library.
You can indeed statically link your module into your C project. The thing to realise is that you need to link in perl too. perl is a library heavily used by Perl code (and it would be so even if Perl code could be compiled to machine language).
perlembed documents how to do this.
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 have a part of my Perl module written in C. The module uses the C pthreads library. I was first thinking to add the C code to my module using a standard XS wrapper but this seems possible only in Perl 5.22 because of this bug report: https://rt.perl.org/Public/Bug/Display.html?id=122906
My C code doesn't really require any interaction with the rest of Perl code. It just reads a file and writes to another file.
In order to not limit my module to Perl 5.22 and up I was thinking about compiling a simple C binary and calling it from my Perl code using systemor backticks.
So my question is: Is it possible to add this kind of target to Makefile.PL and if yes how?
And maybe an input on if this kind of installation process is desirable for a Perl module as I might also just release the C code separately on Github.
To me it seems logical to install it alongside the Perl module as the C binary has no other use than to work with the Perl module.
You can add whatever you want to the generated Makefile by adding a function to your Makefile.PL named MY::postamble() that simply returns the string you want added. This is documented in the ExtUtils::MakeMaker manpage, if you want to read more.
I was using PAR::Packer and this question popped up in my mind. How does PAR::Packer work in Perl? Does it actually compile the Perl script to .exe like g++ compiles C++ Sources to .exe or does it work like py2exe in Python that packs the interpreter and the script into an .exe?
To make this absolutely clear:
Tools like PAR::Packer do not “compile” your Perl script. They bundle the perl interpreter together with your source files and any required modules into a big fat executable file. When it is run, the original sources are extracted and fed to the enclosed perl.
This works reasonably well, but does not yield a speed improvement (on the contrary…). The only advantage is that you can distribute your programs as a single (albeit quite large) file, without dependencies.
There is a very experimental tool called perlcc that is able to translate some Perl programs to C or a Perl bytecode serialization. As the docs put it:
The code generated in this way is not guaranteed to work. The whole codegen suite (perlcc included) should be considered very experimental. Use for production purposes is strongly discouraged.
This is because the Perl language does not support static compilation. It needs to be able to execute code during parsing for some dynamic features during the same session where the main execution phase takes place.
There are other, commercial tools, that usually fall in the same category as PAR::Packer (creating fat executables).
Summary: If you want a single executable, use PAR::Packer. If you want speed, inline some C (or use XS). There is no tool that can compile all Perl scripts to machine code.
I was using PAR::Packer and this question popped up in my mind. How
does PAR::Packer work in Perl?
Does it actually compile the Perl
script to .exe like g++ compiles C++ Sources to .exe
no pp and perl2exe doesn't. (though pp is free).
but it looks like perlcc does
or does it work
like py2exe in Python that packs the interpreter and the script into
an .exe?
pp and perl2exe, yes
As an example- sendemail.exe that looks like something done in PAR Packer or Perl2exe
It packs the interpreter into the exe.
You can open sendemail.exe in 7-zip! There are some folders there but one can't really see it actual files.
I suppose it's some form of self extracting executable, but, that executes code.
You can monitor it with process monitor, and you see.
Or with, process explorer and see if it uses any dll from the temp directory that it creates..
It creates a temp directory e.g.
C:\Users\user\AppData\Local\Temp\pdk-user <--- Win7
or
C:\Documents and Settings\user\Local Settings\Temp\pdk-user <-- WinXP
The temporary directory it creates contains a bunch of strange named DLLs and a DLL called perl58.dll which is no doubt, the perl interpreter
I'm sure at one point I saw it had a dll there with a normal name. SSLEAY32.DLL and interestingly when I ran the pl file it used a dll with a similar name from my c:\perl64 directory. So the EXE looks like a bit of a hack really. It's more reliable to run the pl file directly.
DIR /s/b within that directory, shows-
178c2b604baa8a7f1ebc80539f378bff.dll
1823e8f62785746fd29cf0b06c636600.dll
465d2954d90fe6225ea61b3907c91da8.dll
6145f78a34d5ced8200800f1455d578a <-- the directory with the perl58. dll
9c50b5816b0e35f047e41f5899721d46.dll
f4e2e0db77ed1e6572c2f490479cd815.dll
f72f556d99dfb6b0c3bb37f123e2ee96.dll
6145f78a34d5ced8200800f1455d578a\perl58.dll
no normal named DLLs showing other than perl58.dll (though I have seen a normal one there in the past).
if you look in process explorer, you see it using perl58.dll and other normal named dlls
If you look at the PAR website, a page describes perl2exe
Perl2Exe is commercial, command-line application that can build
standalone executables from perl sources. It works by creating an
executable that contains
A standalone perl interpreter (that is capable of grokking perl 5.8.x)
Your perl script and All perl modules that are referenced by your perl
script.
pp - PAR Packager provides that same functionality, but is free.
And if you look here
http://www.perlmonks.org/?node_id=237943
...the perl2exe tool is not a way to hide your source code.
Now it's even come to the attention of the security community (reported in bugtraq, for example).
For details, see the report from net-security's page.
Please stop supporting perl2exe. Please use PAR for a complete installation package, or perlcc to simply compile the top-level program.
-- Randal L. Schwartz, Perl hacker
So, PP and perl2exe combine the interpreter into the EXE, And you can get an idea that there's something funny atypical about the EXE when it opens in 7zip!
perlcc compiles properly.
it appears to have been unmaintained for a while http://www.perlmonks.org/?node_id=654568 , people said it was buggy, but some work was done on it as recently as June 2014 http://www.yapcna.org/yn2014/talk/5603 It gets better performance than interpreted perl. (unlike the EXEs that pack an interpreter, which are slower than running a perl script normally).
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.
I have a bunch of Perl scripts and Perl modules given to me by someone. I have a driver program that tests all these scripts and modules. I want to generate a call graph and see the flow.
Is there something available for Perl for doing this?
I'd like something like pycallgraph (for python). I am running all this in AIX.
Simon Cozens tells you how to do it in Profiling Perl on Perl.com. He uses a combination of Devel::DProf and GraphViz.