Comment by ptspts
3 years ago
Shameless plug: my earlier project StaticPerl, statically linked Perl 5.10 for i386 Linux and FreeBSD: https://github.com/pts/staticperl
Differences:
* Actually Portable Perl runs on more operating systems, StaticPerl runs on Linux i386 (requiring i686 or newer processor), Linux amd64 and FreeBSD with Linux emulation.
* Actually Portable Perl has more of the standard Perl modules and C extensions bundled. StaticPerl contains only a few modules, simplified, with documentation and non-Linux support removed. StaticPerl is unlikely to work with existing Perl scripts with many use calls, but it is useful to write new Perl scripts from scratch, and these scripts will work with both StaticPerl and regular Perl.
* Actually Portable Perl executable programs are larger (5 MB minimum, StaticPerl is ~1 MB) because they are compiled for amd64 rather than i386, and they contain more Perl and C code.
* The first time an Actually Portable Perl executable program is run, it modifies a few bytes at the beginning of the program file (except on Windows). Thus these programs don't work on read-only filesystems unless they have been run on a read-write filesystem first. StaticPerl doesn't have this limitation.
Author here. Nice comparison. By default (and the released) APPerl binaries do not self-modify (they use the non-self modifying ape loader) however on unix-like they install the APE loader to`$HOME/.ape`and use that ELF executable to run the APE. To skip the fork+exec to the ape loader, they can be assimilated with `--assimilate`, that does turn the APE executable into ELF.
There is a kernel patch to add APE (Actually Portable Executable) support to Linux removing the need for the the apeloader or assimilating. I'm not sure what the status is on that.
I forgot to mention APPerl and StaticPerl have many overlapping use cases, but APPerl is more tailored to application packaging. APPerl is built with a patch to Perl adding argv[0] script execution, allowing the APPerl binary to turn into a binary for any of the embedded scripts, with a rename or symlink rather then needing to pass flags the Perl executable to load modules.
Update on the APE Linux kernel support (for fork/ --assimilate)less APE execution. jart informed me: "It's in the process of being emailed out to the kernel developers. I anticipate it'll be merged within the next three months."
Could you suggest a way to do electron-like apps in APPerl?
I'm thinking of serving content on 127.0.0.2. There is no need for a high performance server like nginx, but serving files and having some CGI capability would be a plus.
I'd be interested in suggestions for the HTTP server part and maybe an example for how do serve an index.pl file that reads payload files packaged in the APPerl binary (ex: .js, .jpg)
I would first create a script that runs a web server that performs as expected (serving files, and handling dynamic functionality in the script or in a perl module, or by paths to cgi scripts as needed). I rolled by own for packing my personal http media server (MHFS), but there's plenty of HTTP servers on CPAN. I'm not sure which one's are best.
Then, I would create a custom build of APPerl using Perl::Dist::APPerl 's apperlm and modifying the apperl-project.json to pack in the script, CPAN modules, cgi files, and the static resources into a APPerl binary. When bundled into APPerl, the script can read the files embedded in APPerl from the /zip path.
Perl::Dist::APPerl (with tutorial on building apps): https://metacpan.org/pod/Perl::Dist::APPerl
MHFS's APPerl packaging config: https://github.com/G4Vi/MHFS/blob/master/apperl/apperl-proje...
5 replies →