develooper Front page | perl.perl5.porters | Postings from November 2009

Re: PATCH #69018; revamped mktables; Makefile changes for it

Thread Previous | Thread Next
Nicholas Clark
November 23, 2009 01:52
Re: PATCH #69018; revamped mktables; Makefile changes for it
Message ID:
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 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?


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

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 Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About