slashpackage

[Mike Porter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 10 October 2003 11:06 am, Paul Jarc wrote:

> Ah.  ATM, I just use a wrapper script called "gcc" to handle that.
> It's found first in my $PATH, but it checks an environment variable
> and adjusts $PATH accordingly, then execs the real gcc.
>

This was actually my original thought, but the consensus appeared to be that 
for performance reasons, this is a Bad Idea; when you are talking about 
taking a buildworld process that already takes 8 hours or so (depending on 
configuration!), and running the thousands of calls to gcc through a 
script...even if it only takes .5 second to work through the shell 
script....that 1/2 second is going to add something like an hour to the 
buildworld (anybody know exactly how may times 'cc' is invoked during a 
buildworld?)  Other packages are even worse (Xfree86, Gnome, Kde...).  Last 
time I tried to upgrade Kde, it took somewhere around 36 hours (OK, so I had 
to update Xfree as part of the process, and there were some build problems, 
so things weren't running continuously--but then too, some things had to be 
run two or three times before I got things straightened out.  Again, adding 
even .5 second to the cc is really not acceptable for "major" builds.  If we 
start accepting that "its OK because it runs MUCH faster on a p4" then we 
aren't that much better than MS (or Linux); there are going to be things we 
simply can't support (frankly, even FBSD doesn't officially support 386's 
anymore, although I think there are some still makeing it work), but other 
things, we need to be sensitive to the fact that we do have users running 
"outdated" hardware.  By maximizing performance wherever possible, we allow 
them to continue, and as long as we don't make things worse for newer systems 
(did somebody say IA-64? <(}: ) then we are still making the world a better 
place.

On an OS that doesn't support variant symlinks, of course, you don't have much 
choice but use scripts and symlinks.  By creating symlinks in users' home 
directories, you can avoid some of the potential conflicts caused by renaming 
symlinks on the fly...As dfBSD is (hopefully) going to have variant symlinks, 
we will have a more direct approach.  Once Matt finishes (starts? <(}: ) the 
vfs abstraction, we'll have more flexibility and power, although the OS will 
need either a registry, a 'resource fork', or some manner of tagged binaries 
to keep the environment straight.  I personally favor a resource-fork 
implementation, since that could be easily edited by hand, but I understand 
the confusion it could cause.



mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/h6o5Y30jZzkECLcRAi0NAJsEl1CFsIeAlKlJvUjBRk6XCAJNrACgrkEC
N4nZuYr74bTcbyPZDwfbEWc=
=y+l/
-----END PGP SIGNATURE-----