Front page | perl.bootstrap |
Postings from July 2000
> Horos <horos@earth.he.net> writes: > >implementation with limits on the size of the arrays. IMO, you should be able > >to configure at compile time: > > > >Include keyword 'open' in perl library? [y] > ... > > > >So, what is really 'in the core' is just the syntax and the C code for > >parsing/interpreting that syntax. The 'outer core' (what we call the > >distribution now) would be intelligent defaults for these answers. The > >'outer outer' core would be a pdk of some sort. > > 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. > Nick Ing-Simmons Ok, I'll go with that, but say you want to turn off certain features, ie: not be able to do system calls, or say use only part of the regex engine, or a different regex engine, or restrict functionality on *purpose*. Or say you want to provide a smaller perl core without the necessary 'help'... I suppose you could provide stubs to say 'this function is not available', or point the perl executable to a different place to find (non-standard) functionality and have compile time directives to turn off these functions. I like it... Ed