On Sun, May 05, 2002 at 08:48:17PM +0100, Mark Murray wrote:
> No need to CC me - I am on the list :-)
[I've culled all the cc's, which I hope is sensible]
> I am strongly in agreement with this.
>
> The FreeBSD core OS needs not much more than the basic language,
> so miniperl's functionality comes vaguely close.
>
> For folks who need the latest/greatest Perl, there is always the
> Perl port, which is distributed with FreeBSD on DVD or CD in
> binary installable format.
Is it well advertised in FreeBSD that by default although there is a
"/usr/bin/perl" installed with some libraries, it is not (and does not
claim to be) the fully featured (including cruft) perl source kit?
And that any FreeBSD user who wishes to have the full thing (as might be
found on some other OSes) needs to install the full perl using the ports
system?
I think that the idea of only putting the perl into the base OS that the
base OS needs is sensible (start from nothing and add as needed, rather than
go the other way and prune). I'm just concerned that users may not realise
that while it's perl as in "/usr/bin/perl" it's not perl as in what you'd
get in /usr/local/{bin,lib,man} if you built from the source tarball.
> Yes. And the core language must have no circular dependancies (need
> X to build X+1). Miniperl is a problem here. Dynaloader needs to be
> buildable using ordinary makefiles.
Currently DynaLoader is written as a conventional extension, in XS, so
needs xsubpp to convert that to C. However, it already cheats as it is
actually colluding with Configure to work out which .xs file to use.
To me, it would make sense to convert the XS to C, and maintain DynaLoader
as C files, not rolled into an extension. It already has enough special
cases (must be static, boot rather than bootstrap, special position in
Makefile.SH) to prevent anyone sane calling it "normal".
> All other modules can be built using something similar to what Perl
> now has, with no significant FreeBSD issues. Builds need to be cross-
> buildable, and all aspects of the build (PATHs, *FLAGS, which tools
> to use) need to be fully specifiable (or overridable) at build time.
> Build choices and runtime defaults need to be separately specifiable.
Cross building means cross configuring, surely? How does a cross Configure
determine what the target can do, when it is running on the build host?
[As other programs are able to cross build, what magic do they use?]
> > 2: Add-on modules (base-perl and site-perl) must be able to fit
> > themselves into an existing perl installation so they can be
> > distributed in prebuilt form.
>
> Yes. FreeBSD's ports system can accomodate this very well.
Is FreeBSD's ports system capable of installing perl extensions on its
own, without needing CPAN modules?
So would minimal FreeBSD perl ship without CPAN.pm, because FreeBSD users
would install from the ports system, not the CPAN mirrors?
Would minimal FreeBSD perl need MakeMaker and friends, or does the ports
system ship things out prebuilt enough so that core FreeBSD userspace tools
are all that is needed?
Would XS extensions from the ports system be dependent on a broken out
ExtUtils "port", so that (say) someone wanting to install the "Socket.pm"
module from the ports collection, would need to get the ExtUtils modules from
the ports as a predependency?
> Would you like to look at the FreeBSD makefiles for Perl, to see
> how much work we've had to do to get the above to sort-of-work?
I presume the answer is "lots" :-(
On Sun, May 05, 2002 at 03:05:13PM -0700, Brent Dax wrote:
> Mark Murray:
> # > 3: The Perl distribution must be split into a core part, and
> # > additional modules.
> #
> # If "core" is just the basic language+Dynaloader, libperl and
> # some documentation, then I am strongly in agreement.
>
> I would imagine that we'd also want CPAN.pm (or CPANPLUS.pm), at least.
> That way we could stick perlbase-(version) and perllib-(version) on the
> CPAN and pull down perllib once we have perlbase built (for a normal
> install--there'd probably be a Configure question asking if you'd like
> to get the standard lib).
I'm not sure. (see above)
Can we divide it into
0: micro perl dist
perl + DynaLoader, minimal libraries (enough to bootstrap whatever comes
next). However, *no* CPAN.pm or likewise. This perl dist relies on the OS
install system (ports, apt-get, whatever) to get anything else.
This would be the sort of thing that FreeBSD, Debian, etc would have in
the base OS for the use of the base OS. With a strong recommendation that
if the user actually wants perl they should install the port, much like
if they wanted to use python or ruby they'd have to install that.
micro perl dist isn't actually "perl", more "miniperl" (see below)
1: mini perl dist
as above, plus CPAN.pm (or equivalent) and enough to download more source
as needed from CPAN
I'm not sure if this includes Socket.pm, let alone LWP type modules, as
CPAN can work with lynx and so forth. I suspect it should contain
Socket.pm and enough simple pure perl modules to get things by http and
ftp (passive and active)
I think it must have Fcntl, File::Glob and SDBM_File in ext (see below)
< current shipped-with-core modules broken out, so people can mix and match >
2: full perl dist
all the modules that will ship with 5.8
If you upgrade 5.8 to this, nothing will stop working.
We've had discussion on p5p about how few extensions you can build without
expecting to fail tests. The consensus reached was that perl isn't proper
perl if dbmopen doesn't work (as it is a builtin), which in turn means that
AnyDBM_File.pm needs to work, which in turn means that one out of
qw(NDBM_File DB_File GDBM_File SDBM_File ODBM_File) should get built.
I think it would be fair for micro perl dist not ship any of the above, and
to document that dbmopen will not work. However, I suspect that mini perl
dist ought to ship SDBM_File, so that it does have a working dbmopen.
Second niggly problem is Fcntl. Andy Dougherty's view (AD in the comment
below) was that it was reasonable for a perl script to expect Fcntl to have
been built. The XS code is now down to this:
#define PERL_NO_GET_CONTEXT
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#ifdef VMS
# include <file.h>
#else
#if defined(__GNUC__) && defined(__cplusplus) && defined(WIN32)
#define _NO_OLDNAMES
#endif
# include <fcntl.h>
#if defined(__GNUC__) && defined(__cplusplus) && defined(WIN32)
#undef _NO_OLDNAMES
#endif
#endif
#ifdef I_UNISTD
#include <unistd.h>
#endif
/* This comment is a kludge to get metaconfig to see the symbols
VAL_O_NONBLOCK
VAL_EAGAIN
RD_NODATA
EOF_NONBLOCK
and include the appropriate metaconfig unit
so that Configure will test how to turn on non-blocking I/O
for a file descriptor. See config.h for how to use these
in your extension.
While I'm at it, I'll have metaconfig look for HAS_POLL too.
--AD October 16, 1995
*/
#include "const-c.inc"
MODULE = Fcntl PACKAGE = Fcntl
INCLUDE: const-xs.inc
with the Makefile.pl not much bigger, but it does need working perl
to build it. And that falls foul of the FreeBSD intent of having core
things build with only "standard" tools.
[Unless you defined working local perl5.005-or-later-but-with-no-libraries
as one of your core tools, and we ensure that Fcntl builds with any perl
version]
However, it would not be the end of the world if my micro perl didn't ship
with Fcntl; Fcntl only appearing at mini perl.
I think that the biggest problem is glob(). [However, looking at the source
I may be wrong]. minimal perl should be expected to work in the time
honoured fashion of calling out to csh (with all the inherent risks) just
like 5.005_03 and earlier.
But proper perl should use File::Glob, as 5.6 and later do.
During the perl build mini perl has a different op.o built with the csh
globbing conditionally enabled, but perl is linked against an op.o with
csh globbing disabled. I'm assuming that my micro perl (above) would ship
without File/Glob/Glob.xs, and use csh. That would mean that a base system
with just micro perl would have /usr/bin/perl that did use csh.
However, upgrading from this micro perl to mini perl (which uses File::Glob)
would mean a new /usr/bin/perl binary. I don't like the idea of a
/usr/bin/perl that switches to csh globbing if it can't load File::Glob,
because that smakes of a security risk. (Take a secure perl which doesn't
go near csh, pervert INC to eliminate the path to the installed extensions,
invoke glob which now silently switches to the csh fallback, exploit bug in
csh, pow!)
If this could be solved, then I think that the whole micro/mini/full idea
would work smoothly, as micro would install /usr/bin/perl and minimal
libraries, and everything else would just smoothly add more modules and
dynamic extensions onto it, without removing or replacing anything else there.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
