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