At 6PM +0200 on 17/05/09 you (Steffen Mueller) wrote: > Hi Ben, > > please accept my apologies for taking such a long time to answer.
Not at all :). > 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. OK. <snip> > 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. Yes, that was the idea :). PAR is great, especially if you've got a whole lot of code in @INC and can no longer remember what depends on what, but I think the remaining minor issues can't be solved without a different approach. In particular, AFAICS the only way around having to unpack the DLLs (with all the associated problems of finding a temporary directory and persuading Win32 to find the right dll) is to link them statically. Since most people don't have a perl suitable for static linking this is means writing a tool for 'experts': people happy building their own perl, and capable of packaging up all their code into CPAN-like distributions. > 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. I was intending to take the common case of single script appended to the exe and pre-build the necessary executable header when the module is installed. This would allow pl2bat-like functionality without a compiler. Anything more advanced than that is obviously going to require at least a linker. > 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. 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. >>> 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. Thanks. 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. 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 :).) Ben
