On Tue, Jun 22, 2004 at 01:19:21PM +0200, Thomas Klausner wrote:
> > My thoughts were to take all of the non-essential targets and
> > supporting definitions/targets etc out into their own file - things
> > like print-PLIST, README, README.html etc, and only include that
> > secondary file if the target was needed.  The idea was that those
> > targets mentioned above (plus others like show-downlevel etc) are not
> > needed in the main scheme of things (and by that I mean:  fetch,
> > checksum, patch, buildlink, configure, all, install), and so don't
> > need to be in the critical path.  I did some timings on it at one
> > stage, though, and found that there was no noticeable speed-up in the
> > grand scheme of things, so I discounted it. I also mentioned this
> > at pkgsrccon2004, but I suppose it got lost in the noise.
> 
> I don't think that speedup is the main target here (though, of
> course, it would be nice to have) -- there's also the idea of making
> it more readable and easier to understand. Also, if one knows that
> in bsd.pkg.extract.mk there is only the stuff to support extraction,
> then it's easier to understand and limit the reach of changes.  If
> all the targets are in one file, there's the additional overhead
> of having to find out that changing a particular part effectively
> only changes the extraction.

Yes, that's a good point, but my personal view is that locality of
reference is a nice thing to have, especially when you are searching
for problems and moving between different targets.  As far as I know,
ctags won't deal with makefile targets properly, and so it's left up
to grep and <editor-of-choice>.  (Well, there's the alternative of
more useful editors like wily and sam, but they are not always an
option).

I have already been bitten by this in the buildlink3 files, and
believe that's the main reason that we have one buildlink expert and
not a number of them.

If the targets are spread out over a number of files, there is no
guarantee that changing a particular part will only change the
extraction, simply that you would have to search through many more
files to find out what has been affected.  In fact, it makes it worse,
as we should be encouraging code re-use, and this sort of thing makes
it much more difficult to achieve.

Regards,
Alistair