develooper Front page | perl.perl5.porters | Postings from April 2002

Re: Save a few hunderd kilobytes or a few hundred perl users?

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
April 30, 2002 15:17
Subject:
Re: Save a few hunderd kilobytes or a few hundred perl users?
Message ID:
20020430221249.GD305@Bagpuss.unfortu.net
On Tue, Apr 30, 2002 at 10:29:00PM +0100, Mark Murray wrote:
> 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.

All the perl developers that I know like writing perl.
Given the choice of writing something in sed sed/awk versus writing something
in perl, which do you think they'd prefer? :-)
In fact, I don't know any awk, and I hardly know any sed.
Then again, I seem to spend more of my time writing perl in C than in perl.

I don't understand the *BSD build paradigm, so I've no idea if I'm making
rash assumptions here, but perl's building paradigm (as I understand it) is
to build a minimal perl (miniperl) and then write the later stages of the
build in perl.

Having done a port to a non Unix system without a shell, it irritates
me that there *are* shell scripts used at all after miniperl is
built. For portability reasons it would be nicer if everything after
miniperl was written in 100% perl, as it's usually possible to
bootstrap a good-enough miniperl from a hand-edited config.h file. But
this is a digression.

Would I be right in guessing that the pain to *BSD in the perl build system
is that even if there is an existing /usr/bin/perl, we perl porters insist
on writing all our perl building scripts using perl features only found in
the perl we're bootstrapping. Hence it's not possible to use the probably
older /usr/bin/perl to finish making perl, and so *BSD has to use the
uninstalled new perl in /usr/obj. Which causes problems bootstrapping new
binary formats (eg existing kernel only runs a.out binaries, new kernel runs
a.out and ELF, new userspace is being built as ELF, but how does one run the
uninstalled ELF perl during make world?) At least, this was the stage where
I had fun when upgrading my FreeBSD box from 4.0 to 4.5.

(This may sound corny or obsequious, but people rarely seem to say thank you,
and assume it's taken for granted. My FreeBSD box works very well. Thank you
for FreeBSD. Please keep up the good work.)

Nicholas Clark
-- 
Even better than the real thing:	http://nms-cgi.sourceforge.net/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About