Hi Ben, hi all,
Ben Morrow ben-at-morrow.me.uk |newsgroups7| wrote:
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?
pl2exe, as currently implemented, compiles and links a new exe every
time it is run. This means it needs a (the) compiler available at
runtime, so it wouldn't be possible to make a PPM or some other binary
package and install it on a machine without a compiler. PAR::Packer
builds parldyn and the rest when the module is installed, so a PPM of
PAR::Packer works perfectly well and doesn't require the user to have a
compiler.
That was quite a thinko on my part. Sorry, it's quite obvious you need a
compiler at executable-generation time.
I've just looked at it now... It looks as though it will do some of what
I want, but I don't really like not being able to see what it's doing.
I agree.
I think I'll keep working on this stand-alone for now, but see if there
is anything that could usefully go into PAR once I've got a bit more
working. It might be sensible, for instance, to use pp as the front-end;
and it ought to be straightforward to teach PAR to load at least
pure-Perl files without unpacking them.
That makes sense to me.
What's the policy on committing to the par repository? Presumably
changes should be discussed here first? (Not that I'm likely to be
commiting anything for a while, but it's best to be clear :).)
There is no clear policy. If you make any significant changes, it'd be
nice if you sent a short mail to the list saying you did so and
mentioning what you did. That helps keeping track. But other than that,
we can always use the powers of our VCS to undo damage if it occurs. If
you plan to do major patching, feel free to discuss it on the list
simply because you may get valuable input.
Cheers,
Steffen