Glenn Linderman schrieb: [...]
So most of the extra run-time cost of pp in the above sequence could be eliminated by doing it at installation time, or at a later "re-run this if you upgrade XS modules". If this sort of packaging of the build time works for all "pre-built" installation techniques, then you have the current performance of pp/par, the bug fixed, and the cost was a more complex build scheme, and a slower installation.
Quite frankly, I am more than happy to trade slower package generation for less frustrated users.
If they have to run some weird script (as root, no less!) every time they upgrade one of the modules which are packaged into parl, they won't do that. They won't because they wouldn't know or if they knew, they wouldn't remember by the time they upgrade. Else, we could just tell them to install a newer PAR binary anyway. But most users won't even surface here. They'll just be annoyed and buy perl2exe or perlapp.
Furthermore, running scripts at installation time for all the gazillions of binary package managers is a daunting and certainly not a rewarding task. That you can only think of PPM being a package manager shows that you're working on Windows only. (Almost) Every Linux has its own package manager. Additionally, you can install .par PAR packages. The PAR Makefile.PL does this if no compiler is present, for example. (Though I control the tool in this case.)
I will not inflict running some tool on upgrades on the users and I won't inflict dealing with installation-time-of-binary-packages scripts on me.
Sorry, but this doesn't work. The whole point of this exercise is to make PAR easier for the user and to remove things they need to remember when administrating a PAR installation.
Steffen
