[email protected] said: > On 18/03/15 20:11, Antti Kantee wrote: > >I think we should follow the adage "first make it right, > >then make it fast". If using a separate compiler for configure is not > >right, and we can't figure out any other solution without obvious > >drawbacks, I'd just as well have configure run slow. > > I tested configure without cc.configure, and it seems to run much > faster than previously, possibly because the stunt-ld step with its > objcopy phase is no longer necessary?
That, and direct use of collect2 rather than ld. > It's still noticeably slower, but not > go-brew-yourself-a-cup-of-coffee-with-a-manual-drip-filter slow anymore. Yes. > > I removed cc.configure and specs.configure. That doesn't mean we > shouldn't make them faster some day, but for now I'd rather have > working cmake and libtool. Good. A problem solved by removing code is well solved :-) Ok to remove STUBSOBJ also? It was only being used by the configure specs. Further, I'd like to remove the -configure, -make and -gmake wrappers entirely, but we need to sort out the naming issue first.
