Date: Tue, 30 Apr 2002 23:43:09 +0100 From: Mark Murray <mark@grondar.za> To: Nicholas Clark <nick@unfortu.net> Cc: freebsd-current@FreeBSD.ORG, perl5-porters@perl.org Subject: Re: Save a few hunderd kilobytes or a few hundred perl users? Message-ID: <200204302243.g3UMh9oI033720@grimreaper.grondar.org> In-Reply-To: <20020430221249.GD305@Bagpuss.unfortu.net> ; from Nicholas Clark <nick@unfortu.net> "Tue, 30 Apr 2002 23:12:50 BST." References: <20020430221249.GD305@Bagpuss.unfortu.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. I wonder why that is? ;-) > Given the choice of writing something in sed sed/awk versus writing something > in perl, which do you think they'd prefer? :-) No brainer! :-) > 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. BSD's build paradigm is to do it all in makefiles, using make's dependancy rules. > 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. Hand crafted config.h files are a pain if you need to do some configs (word size, endianness, build vs. run architecture, etc). If you use system headers for this, then you are laughing. If building scripts (say, perldoc) is as simple as running a script through (only) miniperl, that would be OK - miniperl could be a part of the OS build toolchain. I had something in mind like %%FOO%% strings that would be simple to sed(1) into their real values at build time. I am under no illusions that doing this is major work for you guys. > 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. That is a big part of it. Another big part of the the problem is that build time requirements become run-time defaults, like where you put stuff for the build vs. where stuff is eventually put stuff at install time. This is particularly bad when trying to cross build, as perl decides at build time what CPU it is going to _run_ on, and fouls up :-). We've mostly fixed that, but it is very fragile, and I'm dreading the next perl upgrade. *BSD can fix most of this using the right headers (eg: sys/endian.h) and the right integer types (u_int32_t, int64_t, etc). We've dethreaded lots of the build, and we build libperl.(so|a) mostly with straight makefiles. We can build perl, suidperl and miniperl with just a little bit of scripting magic (mostly for Dynaloader), but the dependancy list is very big (MakeMaker etc). > (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.) Thank you for Perl! We gripe about its build, but it is a very useful tool. Thank _you_! And a very hearty "Thank You" for this opportunity to discuss this thorny issue with you! 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?200204302243.g3UMh9oI033720>