I think you're mistaking my comments for expertise. I really have no clue *why* the makefiles are the way they are. I don't know enough about makefiles to be comfortable debugging them.
So I'm not objecting to having the makefile build from srcs. I think it's a good idea. I try to keep my changes forward compatible with existing bands so I don't introduce `evolutionary drift'. I try to make them compatible with existing behavior mostly because I don't know enough about the existing behavior to be comfortable with changing it. > So... my patch was unnecessary, BUT helpful for a newbie? Yes. I have long wanted a more linear, if longer bootstrap. In the old days, it was insane to run SF interpreted in order to SF itself. There simply wasn't enough memory. Then there wasn't enough time. Now it's reasonable. > It did not > solve your infinite loop problem? I've basically `solved' it by expanding named LET expressions into an internal definition. Logically, this is equivalent, yet there is a bug, and I'm curious about it. > Are you saying the extra work now done by compile.sh is NOT worthwhile > even if it allows newbie to build from source THIS time? No, no no I think it is great! I'm really sure that won't have an effect because I tried to make real sure that my changes don't need that bootstrapping step. That's because I don't know why that bootstrapping step is there, so I don't want to try to `fix' it, so I really really hard not to write code that might need a bootstrapping step like that. That's all. > > I don't suppose we can avoid the problem in general, so your note is > bound to be helpful. I just thought it was crazy to continue building > a new compiler with the old compiler present. > > The LIAR/C build MUST take this precaution, yet it also stopped > working mid-January. When I hacked compile-boot-compiler.sh like > compile.sh I was able to build it with 9.1.1. I guess the problem was > an incompatibility between the old sf (and/or runtime) and the new > compiler. -- ~jrm _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
