demerphq wrote: > 2009/11/24 karl williamson <public@khwilliamson.com>: >> Attached is a patch to cut down the frequency of mktables running. It turns >> out the problem was a combination of both Makefile and mktables. I didn't >> realize that the files I removed were listed as dependencies in Makefile, so >> it always thought it was out-of-date, and called mktables. Part of the old >> code I hadn't changed caused mktables to remove all the files when called >> with the -makelist option. This code is no longer necessary, so I removed >> it. >> >> I also changed Makefile to always call mktables, to let it decide if it >> actually should recompile. I just commented it out for easy reversal. The >> problem is that mktables depends on almost 800 files, located in the To and >> lib subdirectories, and Makefile doesn't know about them all; and they >> change from Unicode release to release. I'm assuming mktables.lst was >> created because of the issues of trying to get them all known by Makefile. > > Yes, and also because we used to basically just generate them all, and > there was no list, we just had dependencies on a few files, and for > some irritating reason mktables would run like, umm, 6 times on win32. > And so back in the day it used to regenerate everything each of those > six times. So i taught it about the list of files and made it more > intelligent so that it doing things over and over turns into a noop on > following runs. Please dont make it too slow, in particular certain > stat calls on win32 are effectively a file open on every file in the > tree. If you do do that pleasee enable sloppy stat. > > cheers, > Yves > I don't know about sloppy stat. But the patch does fix the bug in which mktables got it wrong about needing to run or not. On my Linux/Vista box (this year's model) it compiles in under 30 seconds, and now doesn't redo itself unless it should.Thread Previous | Thread Next