Front page | perl.perl5.porters |
Postings from November 2009
On Sun, Nov 22, 2009 at 10:46:26PM -0700, karl williamson wrote: > There needs to be some discussion about how mktables gets called. It > generates all three of t/re/uniprops.t, lib/unicore/mktables.lst, and > pod/perluniprops.pod (besides Heavy.pl and all the tables). I meant to > I was attempting to add the generation of all three of them to Makefile > because of what Nicolas said several months ago about wanting to > generate the pod file every time, as it was one less thing for the > pumpking to worry about when getting things out the door. I figured > that we should be consistent, so made that the behavior for all three. > But this is a change for mktables.lst. I don't know when that got > generated in the past. Perhaps it is something on the pumpking's list? > > I see a couple of possibilities. One is to generate all three every > time. I guess that means they should come off the MANIFEST. But > mktables.lst has always been generated, and has been in MANIFEST. > > The other option I see is to generate them by hand when a new release of > Unicode is installed, and to put them in the MANIFEST. But if someone > changes mktables to generate different files, these would have to be > regenerated at that time as well, and someone might forget. > > What are people's opinions? Tricky. The logic to run tests 1: needs to be simple, because it needs to work well enough if perl has not built correctly 2: currently relies on getting a list of tests to run from MANIFEST (which is consistent with point 1 - it is KISS) The simplest way to sit within those constraints is to have t/re/uniprops.t as a wrapper which requires a generated file. (No, this isn't totally clean. But I can't see a cleaner way to do it) I also continue to feel strongly that it is wrong ship generated files if we can avoid it. Shipping generated files 1: pessimises the size of the release 2: increases work, and chance of mistake, on people maintaining the core. in particular, it adds items to the checklist of things to do before a release. Given full information about dependencies, make is a very good tool at knowing what *doesn't* need doing. If the current setup is needlessly regenerating things, then that's the avenue to fix first. Also, you mentioned Encode and the files it generated. I found a lot of scope for optimisation within enc2xs, which dramatically decreased its memory use and run time, without needing large fundamental design changes to how it worked. And I managed that with only Devel::DProf. I'm curious what can be achieved with Devel::NYTProf on mktables. (Which is a task that is within the skill set of any of the 600 subscribers to this list. I'm hoping that it might appeal to at least one.) Nicholas ClarkThread Previous | Thread Next