Said Nicholas Clark <[EMAIL PROTECTED]>:
> > 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?
For the latest release, FreeBSD Perl is the full deal.
For CURRENT, we are still discussing this. What you ask above is
possible, if we go that route.
> 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.
See the other threads about perl-base vs perl-libraries.
> > 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".
Agreed.
> > 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?]
FreeBSD may be running on i386 but compiling for alpha. It knows what
the alpha defaults are, and does not want the i386 defaults to override them.
> > > 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?
BSDPAN :-)
> So would minimal FreeBSD perl ship without CPAN.pm, because FreeBSD users
> would install from the ports system, not the CPAN mirrors?
Sorta. BSDPAN, plus our pkg_* utils, similar in concept to RPM technology.
> 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?
MakeMaker would be needed to build the ports, but not to install prebuilt
ports.
> 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?
I don't know. Does Socket.pm depend on ExtUtils as a run-time dependancy?
> > 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" :-(
Right! :-)
> 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.
Sounds OK.
> 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.
Or install the perl library as a port.
> micro perl dist isn't actually "perl", more "miniperl" (see below)
But as it has Dynaloader, and can install the perl libraries, it can
become "real" perl.
> 1: mini perl dist
> as above, plus CPAN.pm (or equivalent) and enough to download more source
> as needed from CPAN
FreeBSD has its own port distribution system. BSDPAN would be used,
and many users would want to use the freeBSD port system to build
the modules.
> 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)
The current perl dependancy tree would make this a _big_ list.
> I think it must have Fcntl, File::Glob and SDBM_File in ext (see below)
Pretty much most of what is there now. Notable exception - CGI.pm.
> < 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.
AAAARRRGGGH! ;-)
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
