Front page | perl.bootstrap |
Postings from July 2000
At 6:05 PM -0700 7/24/00, horos wrote: > > >Include keyword 'open' in perl library? [y] >> > Include support for 'http' in 'open' [y] >> > Include support for 'ftp' in 'open' [y] >> > Overload 'open' with other support (https, etc)? [n]; >> >> Then you could say good-bye to portable Perl scripts. >> > > --tom > >[snip] > >Monolithic is good, but only up to a certain point. But ultimately >you run into >the MS problem, where they try to make 'one size fit all'. I don't >want to have >only two sizes to perl: big and humongous. But that is the way it currently >stands... I agree, but I'd think something along the other end of the spectrum: $ ./configure --remove-functionality *** WARNING: If functionality is removed from this binary, some existing Perl6 Applications may not function properly or at all with this binary. This optionis recommended only for experts who have a very good grasp of what they are doing. Are you sure you wish to proceed? [n] Y ** OK, YOU ASKED FOR IT. Remove keyword 'open' from perl library? [n] Include support for 'http' in 'open'? [y] Include support for 'ftp' in 'open'? [y] N ** FTP SUPPORT IN OPEN REMOVED ** And then: $ ./perl6 -V <blah blah blah> NO_FTP_OPEN NO_OTHER_REMOVED_FEATURE NO_BLAH NO_FOO NO_BAR <blah blah blah> So that by looking at the verbose info, you can (as someone dropped there) see if someone has boned the version of perl you're using and deal with it accordingly. You're right that embedded platforms don't require good chunks of the code, but I think the trick is to treat them as the ANOMALY rather than the base from which you build "up". Strip "down" to embedded platforms, but make sure the non-embedded system has a consistent set of available functions unless someone has fscked with it. My $0.02 worth. D