On Thu, 21 Sep 2000, Nathan V. Patwardhan wrote:

> I don't think that the documentation should be removed from the core
> distribution, BUT I do think that there should be an "easter egg" that
> allows people to build a Perl distribution without documentation or
> whatever else they choose.  There have been times that I've
> wanted/needed to build a "tinyperl" (even smaller than "miniperl" :-) )
> and I've had to hack things significantly to Make It So.

[This is not a stdlib issue.  Issues about building perl should go to
perl6-build.  Issues about redistributing such an incomplete installation
should probably go to perl6-licensing.  Please adjust followups
appropriately.]

The number of possible permutations of "whatever else they choose" is
extremely large.  I can understand the desire to build a tiny perl
targetted for a specific need, but I also understand there can be very
very many different specific needs, and hence there is no single
"tinyperl".

Nevertheless, much of the necessary infrastructure is currently available
in perl5 by fiddling with Configure command line options or config.sh.
(e.g. you can omit all socket functions but keep SysV ipc.) There are,
however, no pre-supplied tools or makefile targets to make it easy to
build a particular targetted "tinyperl".

Though the perl6 configure/build structure may well be quite different
from that used in perl5, it still seems likely to me that there will end
up being some sort of Config.pm database used in building perl. Hence that
same underlying information will likely be available.  Further, the Perl6
distribution may well be less monolithic, which would make it somewhat
easier for you to drop out specific parts.  For an extreme example, you
might be able to simply replace the entire regular expression machinery by
a simple die() call, if you know your tinyperl will never use regular
expressions.  Such a tinyperl is clearly not a complete perl distribution,
but it might still be the appropriate tool for some particular use.

In short, this seems to me to fall under the general "hard things should
be possible" rubric.  Making the build process fairly modular and keeping
a Config.pm record of what this particular perl binary can and can not do
are both seemingly reasonable goals for the perl6-build process.  If
someone wants to write a tool to leverage that infrastructure and make
this hard thing a bit easier, then I don't have any real problem with
that.  Such a tool could even be written now.  I just don't think the
perl[56]-build teams should be expected to spend too much effort on making
it easy to build incomplete perl installations.  There are too many other
important problems.

-- 
    Andy Dougherty              [EMAIL PROTECTED]
    Dept. of Physics
    Lafayette College, Easton PA 18042

Reply via email to