2008Q4 Grant Proposal: single-file GUI-enabled executable for Windows and Linux

Category: Grants

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.



Sign in to add comment