> > well, I fiddled around with pp-0.79, and this is what I came up with for > > objectifying it. > Whoa. Most impressive. You have completed in one day what I have > delayed for one year. :-)
not quite... its completed if you don't care about a somewhat ad-hoc App::Packer interface. ;-) As it sits, the backend does most of the work. The frontend is equivalent to Module::ScanDeps and is used in the same way; but the manifest, etc are kept in the backend, not the front end. So are the files; App::Packer::Backend::PAR contains the manifests, etc. Perhaps this is the way it should be - it was definitely easier this way than to try and talk back and forth between the frontend and the backend. And pp does some weird things with both selection of the input and output files (notice '-e' and such) > > It should be backwards compatible with App::Packer, but some testing should > > be done if it was to take its place. Same with pp - hence I attached > > the objectified pp as pp_new. > Mattia, can you look at App::Packer::Temp and see if it can be merged > back to the main App::Packer? I'm most willing to move the "pp" script > into part of App::Packer, and make App::Packer a prerequisite of PAR, so > that they can be separatedly maintained and updated. > Why do we not make this yet another option to pp (i.e. > App::Packer::Backend::PAR)? well, I did it both as an example of usage (it uses the method app_manifest), because it uses generated code, and has potentially different options than pp. It also is only one possible way to implement ppack (tkpack or wxwinpack comes to mind) > > I'm not particularly attached to the style (tabs > > and lots of parens), so feel free to change it back if you > > want to include it in the standard distribution. > > That's what PerlTidy is for; don't worry about it. :-) I guess I was sort of hoping that someone would go through it and manually change it back - just for error-checking sake. I'm confident in my code, but I'd like some human eyeballs on it. Ed
