Hi Ben, hi all,
I'm both a PAR maintainer and a PAUSE admin. I'll try to keep the
comments on the namespace and the general remarks separate.
Perl Authors Upload Server wrote:
modid: ExtUtils::PerlToExe
description: Build a binary executable from a Perl script
similar:
PAR::Packer pl2bat
Namespace: Depending on where you want to go with the project, maybe a
"branded", probably top-level, namespace would be more appropriate. On
the other hand, if you're really going to stick to having this a
"pl2exe" tool, maybe one of these would be appropriate:
ExtUtils::Pl2Exe (conveys the idea that it's about converting perl
*scripts*)
App::Pl2Exe (see above comment and also stresses that it's a tool
similar to pl2bat)
I'm also not sure about ExtUtils, but I guess if you don't like the
App:: prefix or "branded" namespace ideas, it's as good a place as any.
Please let me know what you think. I'm also willing to approve
ExtUtils::PerlToExe.
rationale:
This module builds binary executables from Perl scripts. Unlike
PAR, these executables don't need to unpack themselves before
running. Currently the module can't pack up an @INC tree along with
the script, so it's more of an alternative to pl2bat than to PAR.
I'm not entirely convinced ExtUtils is the best place to put this
(it hasn't really got anything to do with building extensions), but
I couldn't see anywhere better. If you have any suggestions I'd be
glad to hear them. I haven't uploaded it yet in case the name
changes.
Now speaking as "that PAR guy".
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.
I really like the idea of NOT unpacking the stuff. This temporary
storage thing has cost me more hair than my girl-friend likes and it
just seems to be such a terrible hack to start with...
My plea to you is that instead of starting from zero and then having to
reinvent all of the wheels we've been working hard to provide with PAR,
you could join the team and try to make it fit in with what we have. I'm
actually not sure which way is easier. It's no secret that the PAR code
is crufty, but it is for a reason: The problem is a difficult one. But
maybe you're just the right guy to solve this?
Cheers,
Steffen
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.
