Date: Fri, 22 Jun 2007 16:14:33 -0700 From: "Jordan K. Hubbard" <jkh@brierdr.com> I realize the pain involved in going this route, but it seems like we're trading mere compilation time for engineering time, and the latter is almost always more expensive. What engineering time is involved, aside from implementing the small change I proposed (which I imagine would be very easy), assuming it doesn't seem a bad idea? I do understand your desire to not heat up your lap, but speaking from just my personal viewpoint, I'd far rather have a nice, generic port which took an hour to compile than have to figure out which of n ports to use and also deal with the fragility of these ports over what could be multiple OS releases and variable availability of suitable bootstrap compilers for whatever architecture / word size (ppc, ppc64, x86_32, x86_64, and so on) I might be trying to target. Yes, I'd like to avoid this kind of complexity too -- which is why I meant exactly what I said in my previous email. If there is an existing native build on the system, then I want the native port to use that; otherwise, everything has to go through the C build. I'd like to avoid any cross-compilation complexity, except from C to native or vice versa, so I have no intention of having separate `mit-scheme-x86_32', `mit-scheme-x86_64', `mit-scheme-ppc', &c., ports. Just `mit-scheme-c' and `mit-scheme-native'.