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. Thanks, I've applied it now. > 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. > > I did a search for the removed files and removed the only other reference to > them (in .gitignore); except I see them in Makefiles for other platforms. I > assume these get automatically generated from the changed Makefile.SH Well, no : they will need adjustment too. But I don't have Windows or VMS machines or knowledge to test. > I also changed some typos in comments, rephrased a little of the > documentation, removed a no-longer-used subroutine, and fixed another bug, > in which it would fail to run if there was no mktables.lst at all, added -p > option to its call. > > I'll work soon on a wrapper to the .t. I'm wondering though about the > generated pod. It should be put into the toc, etc. Would a zero-length > place-holder that mktables overwrites be the right solution? That's a good point. I added it already in pod.lst. I don't think that a placeholder is necessary for the pod file. I'll have a look at it.Thread Previous | Thread Next