Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Apr 2002 22:29:00 +0100
From:      Mark Murray <mark@grondar.za>
To:        Johnny Lam <jlam@jgrind.org>
Cc:        freebsd-current@FreeBSD.ORG, perl5-porters@perl.org
Subject:   Re: Save a few hunderd kilobytes or a few hundred perl users? 
Message-ID:  <200204302129.g3ULT1oI033122@grimreaper.grondar.org>
In-Reply-To: <20020430134041.A11328@jgrind.home> ; from Johnny Lam <jlam@jgrind.org>  "Tue, 30 Apr 2002 13:40:41 PDT."
References:  <20020430134041.A11328@jgrind.home> 

next in thread | previous in thread | raw e-mail | index | archive | help
> I think Perl should be broken into two pieces: a "miniperl" distribution
> that is called "Perl" and a separate "Standard Perl Module Library"
> distribution.  They would be versioned separately so what's considered part
> of the core Perl language isn't confused with what version of CGI.pm or
> other random module is included with a Perl distribution.  It's clear that
> the modules evolve much faster than Perl's release cycle, so the Perl
> Library distribution could simply be on its release cycle.

I would be _delighted_ with this arrangement! *BSD could use the
"Perl" dist, and libraries would be excellent ports-fodder.

> NetBSD (I) used to separate out Perl into a separate "miniperl" package +
> extensions, but I gave up on doing this because it was just getting to be
> a maintainence headache -- with every Perl release, I had to wade through
> a different module list to see what should be removed and what should stay
> and I just got fed up with the extra work.  This is a lose for some of our
> platforms that just don't have a lot of disk space to spare, e.g.
> NetBSD/hpcmips.  With a Perl + Perl Library setup, we could more easily
> control via a package system which modules are installed in a simpler,
> more additive way.

A headache that would need to be addressed (IMO) is the one where
Perl makes too many decisions about runtime at compile time. This
makes things like cross building a real PITN.

If the above "Perl" was really minimalist, that would be good. If
it was basically some .c/.h (and .l/.y) files making the core
language + Dynaloader, with no need to execute _any_ perl during
the build, that would fit into the *BSD build paradigm very well
indeed, and that would probably support the "Standard Perl Module
Library" subsystem very well indeed, with no circular dependancies.

A _big_ headache is the config.sh script that is sometimes read by
a perl script, thus breaking any chance of putting shell variables
and expressions in there and having them expand properly.

Perl stuff like perldoc, pod2man we would like to be able to build
with sed/awk scripts if necessary.

I fully recognise as a programmer that this is not trivial work :-).

M
-- 
o       Mark Murray
\_
O.\_    Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204302129.g3ULT1oI033122>