Hi Ben,
please accept my apologies for taking such a long time to answer.
Ben Morrow wrote:
Quoth nj88ud...@sneakemail.com (Steffen Mueller):
There's an experimental branch of PAR::Packer/PAR in the PAR repository
that does not unpack any Perl modules courtesy of Scott Stanton.
Naturally, this is a much bigger problem for shared libraries or
arbitrary data files which might be packed alongside the Perl code, so
we never managed to sanely merge that into the main line of development.
OK, I've had a quick look at that (am I right that the relevant bits are
the PerlIO::scalar stuff in /par/PAR-Packer/branches/fastio/script/
par.pl?) and it looks like the most important difference from what I
have is that it unpacks into memory. I was trying to avoid that, as
well, by using PerlIO::subfile like ex::lib::zip.
This is why I'm CC'ing Scott who created the fastio branch. I'm not
really all that familiar with his changes.
What I have at the moment is up at
http://github.com/mauzo/ExtUtils-PerlToExe , if anyone is interested.
I've had a (very) quick look. At first sight, I didn't grok most of the
code that relates to the ExtUtils::* modules you're using, but I haven't
had the time to look at those either.
You are right that I was intending to write more than a simple
replacement for pl2bat :). My plans were
- to write a Perl::Dist subclass that knows how to take a Perl
application (in the form of a CPAN distribution) and build an MSI.
The idea is to make this MSI behave as much like a generic Win32
application as possible, so it would install its own copy of perl
and all needed libraries, and have an app.exe entry point (built
with pl2exe). It would also need to be sure not to interfere with,
or be interfered with by, any other perl installations on the same
machine.
To be useful, this would need to be a 'Portable'-type perl. It
would also need to be able to work from a directory with spaces in
its name. My intention was to start by unpicking the Perl::Dist
stuff to understand how it works, and then work out what is
currently possible and what isn't.
I think a lot of that is still TODO: MSI (high up on Adam's todo list),
the ability relocate the installation at will, and the spaces issue.
- to extend pl2exe to allow it to create statically-linked
executables. My idea was to get around the dll-loading problem by
building all the needed extensions statically, then including a
zip of the Perl code on the end of the exe the way PAR currently
does. It's easy to read Perl from there without unpacking it,
using PerlIO::subfile and the code from ex::lib::zip, though there
are issues with taint mode.
Since most perls in the wild aren't built for static linking, I
was assuming I would need another Perl::Dist subclass here that
knows how to build one. This would mean I would be using the
Perl::Dist dependency logic (following the CPAN dependencies)
rather than Module::ScanDeps. There is also the issue of teaching
Module::Build how to do static linking, but I was planning to look
at that when I got to it :).
I don't know how well any of this meshes with what PAR is trying to
achieve. For a start, I am assuming a C compiler and sources for
everything will be available, which PAR goes to some trouble to *not*
assume. I don't know whether maybe that decision could be reversed (or
at least, whether features could be added that *do* require a compiler)
now that Win32 users have Strawberry Perl: are there any other systems
where a compiler is typically not available? (Could they get Strawberry-
type distributions too? :) )
I do realise all this is likely to turn into a huge undertaking, but
hey, I never got anywhere by being under-ambitious.
This all sounds like a very useful tool. I asked you to come here and
tell us about your plans in the hope that it may be useful to combine it
with PAR. However, what you propose has the same general goal
(deployment), but it goes about it quite differently.
I'm not sure what you mean by adding features that require a compiler.
PAR::Packer requires a compile and the perl headers to build alright.
Can you elaborate?
By the way, have you looked at Mark Dootson's Cava packager? It's
essentially a tool to generate an executable with a lib/ that contains
all that's necessary to run the perl app. It's closed source, though.
PS: If you don't have write access to the PAR repository already and
would like to get access, just let me know and I'll set you up. You'd
need an openfoundry username.
I don't. I've just signed up to openfoundry as mauzo.
I added you as a project admin.
Cheers,
Steffen
