2008Q4 Grant Proposal: single-file GUI-enabled executable for Windows and Linux
Sun, 02-Nov-2008 by
Alberto Simões
edit post
<![CDATA[
* **Name:** Vadim Konovalov
* **Project Title:** single-file GUI-enabled executable for Windows and then for Linux w/o temporaries and dependencies
* **Synopsis:** Proposal is to make a distribution of Perl program with a single-file executable much like PAR approach but without any temporaries, thus having existing filesystem untouched in any way. This executable will include Tcl/Tk into it and all Perl and Tcl/Tk core scripts will be inside this executable and will be unpacked on demand into memory.
**Name**
Vadim Konovalov
**Project Title**
single-file GUI-enabled executable for Windows and then for Linux w/o temporaries and dependencies
**Synopsis**
Proposal is to make a distribution of Perl program with a single-file executable much like PAR approach but without any temporaries, thus having existing filesystem untouched in any way. This executable will include Tcl/Tk into it and all Perl and Tcl/Tk core scripts will be inside this executable and will be unpacked on demand into memory.
**Benefits to the Perl Community**
Having a possibility of distributing applications is a frequently required feature. A potential user could have no Perl installed, or it could have incompatible version or lack some CPAN modules. Fortunately there are several ways to solve this problem. All these solutions are having drawbacks however. For example, PAR extracts all files into some temporary directory and then runs a program from there, thus having at least 3 un-effectiveness problems: it pollutes filesystem with temporaries (what if there's limited space on TEMP), it extracts all script files - even script files that are not actually needed (actual program run could skip), and also it creates extra subprocess, which is needed to startup properly.
There are also non-free solutions, but those are not available to everyone and so these could not be adviced as a solution to a problem.
Proposed by me approach will produce executables with following properties:
* a single executable of about 8 Mbytes in size (this is for perl-5.10.0, earlier versions could be smaller)
* required modules will be statically built into this executable (including Tcl/Tk)
* this executable will have ZIP content inside it, whith all needed Perl and Tcl/Tk scripts. extraction from this ZIP will be done in-memory on the fly (when required).
* GUI is done with Tcl::Tk CPAN module, with Tcl/Tk of version 8.5.3. Starting from 8.5.0, Tk on linux has much more attractive look-n-feel (compared to Tk8.4 on linux)
To mention, Tcl/Tk have similar approach of creating executables (starkit, tkkit). Also all major Common-LISP implementations have possibility to produce single-file executable for easy distribution. Perl needs some efforts to be in par with both Lisp and Tcl.
**Deliverables**
A set of scripts to generate executables from existing programs will be created. Also, core Perl modules should be prepared for static linkage, and this part could require changes into the Perl core itself.
**Project Schedule**
On average I will spend every day for two hours implementing required functionality and will complete windows part within 7 weeks and linux part within another 3 weeks.
**Bio**
I have experience of Perl programming for more than 10 years, my CPAN ID is VKON. I also have experience in this particular area, i.e. on distributing Perl-based GUI-enabled deliverable executables based on about 5 files without temporaries.
**Amount Requested**
I would like to ask a total of $3000.
]]>
Comments (2)
I can see this for .pm, but how would you load .bs/.bundle and .dll/.so/.dylib files without a filesystem representation? I thought that was not possible.
I saw the comment about static linking, but that means you could not use any XS that was not built into the original executable. Is it easy to statically link arbitrary XS modules? Does this mean you relink the executable for each build?
I commented on this proposal in the previous round of grant submissions:
previous comment and won't repeat my reservations here. Vadim replied in a comment further down that he doesn't plan to reinvent any wheels. However, I haven't seen compelling reasons why he can't get involved in the PAR project and fix some of its shortcomings instead of rewriting a lot. Yes, PAR is daunting and crufty, but it does some things well. Even if those don't quite fit the bill, by integrating the proposed improvements instead of reinventing, everybody gains in terms of maintenance load later on. I shudder at the thought of duplicating that effort.
Then there's mention of building Perl modules statically. Doesn't that mean the user (aka. application developer) will have to compile a fresh perl if he needs another XS module? Ouch. How much effort would it take to add, say, DBI to the mix? The DBDs? wxPerl? Template Toolkit?
It's in the linked comment, but let me paraphrase the last bit: The core of my criticism isn't related to whether Vadim can implement this entirely or not. It's about whether the proposed solution is the most beneficial to the Perl community.
