On Tue, Jul 25, 2000 at 03:08:02AM +0000, Nick Ing-Simmons wrote: > I would go slightly further in one direction, and not as far in another. > That is I would always build 'perl' as the minimal thing. BUT I would > include in that minimum the ability to dynamically load the other bits. > > Umpteen different perl executables with different capabilities > is not easy to manage. One tiny perl which adapts to how it is used > by calling for help should be. Implicit in the second paragraph is that any perl which is built with some features compiled out of the core should automaticly have those features moved into the modules. IMHO (and I speak from experience here) it would be a big win to be able to, at build time, compile any well-behaved module into the perl core. We have a number of modules which we effectively require be in every perl application (carp, strict, Dumper, more); it'd be nice if the `standard' corporate perl executable simply had them all in it rather than load them on each of the thousands and thousands of perl runs we do daily. Ultimately this could even result in a perl which consists only of the ability to run a given application, but in near-complete standalone mode from the `generic' perl & modules that happened to be installed on a given system. This would greatly ease the chance that a perl program might *never* need to worry about backwards-compatibility because it carries most of its environment with it.