A new and better way to do "make readmes"?

Conrad J. Sabatier conrads at cox.net
Sat Jan 28 16:28:45 UTC 2012

On Sat, 28 Jan 2012 14:37:34 +0000
RW <rwmaillists at googlemail.com> wrote:

> On Fri, 27 Jan 2012 20:03:25 -0600
> Conrad J. Sabatier wrote:
> > I've been thinking for a long time that we need a better way to do
> > "make readmes", one that would be properly integrated into our
> > ports Mk infrastructure, to take advantage of make's ability to
> > recognize which files are up-to-date and which really do need
> > rebuilding.
> This wont help and I think there's a better way that will make it up
> to 700 times faster.
> When a make readmes is done at the top-level, the top-level and
> category READMEs are created by make targets and the per port READMEs
> are created by a perl script in one go from the INDEX-<n> file. 
> I once timed this and the 64 category  READMEs took 2 hours, but the
> ~20,000 port READMEs only took about 9 seconds.

<rubbing eyes in disbelief>  Am I understanding you correctly?  Are you
saying you built 20,000+ port READMEs in only 9 seconds?!  How is that
possible?  Or do you mean 9 seconds for each one?

> Selective updating isn't going to help because 99.9% of the time is
> spent in the categories and it only takes a single port update to
> make a category file obsolete.

This is the part I find troubling.  It would seem that it should be
more work to create an individual port README, with its plucking the
appropriate line out of the INDEX-* file and then parsing it into its
respective pieces and filling in a template, than to simply string
together a list of references to a bunch of already built port READMEs
into a category README.

What am I not getting here?

> I think the way to speed this up is to have the script generate the
> category files too. There's no point in bringing in the top-level
> README since that's already fast.

So what's making the category READMEs so slow then?

> I've been toying with the idea of doing this, but have never got
> around to it. If anyone wants to have a go I think it would be
> sensible to write it in awk, since perl is no longer in the base
> system and the existing perl script isn't really complex enough to be
> worth hanging-on to. 

Oooo, awk!  Been a while since I wrote any sizeable bit of code in it,
but I do remember it was rather fun to work with.  :-)

I'm still not sure I read that paragraph above correctly, though (re:
the times).  :-)

Conrad J. Sabatier
conrads at cox.net

More information about the freebsd-ports mailing list