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/