Looking for speed increases in "make index"

Mark Linimon linimon at lonesome.com
Mon May 28 01:44:57 UTC 2007


On Mon, May 28, 2007 at 12:15:28AM +0200, Michel Talon wrote:
> To gain some performance, a first idea would be to simplify
> bsd.ports.mk. I am convinced that a substantial part of the 4000 lines
> are historical crap which serve no useful purpose.

11272 of LOC in bsd.*.mk, but who's counting.

> There are tons of variables who have probably purely anecdotical
> interest. There are targets which could be happily suppressed.

Please let us know which functionality you think is extra.  You should
use the individual port Makefiles as well as ports/Makefile to figure
out what is unused.  For extra credit, please include
ports/Tools/portbuild/scripts so the build cluster will continue to work.

Please don't think I am picking on you specifically; however, about every
6 months or so someone decides that "the ports framework is too complicated"
without saying exactly what needs to be removed.  Since I look at all the
portmgr PRs as they come in, and participate in rejecting in some of the
(by our determination) more marginal features, I can assure you that not
every single new proposal makes it in there, nor has in the past.  Every-
thing that's in there is because there was some specific justification for
it (at least at the time).

Given that we had no install base, a significant rewrite would not be a
burden, but that's not the case.

Please note, I've agreed for several years that a great deal of the code
could be factored out into some kind of C library for speed and reduction
of code duplication.  Some work is going towards that in the Summer of Code.

But the hard part is making it work, in a backwards compatible fashion,
and doing the exhaustive regression testing to prove that it solves more
problems that it creates.  (portmgr spends a _lot_ of time on regression
testing, behind the scenes.)

In summary, the ports infrastructure is really complicated because it's
trying to deal with all kinds of constraints and conditions.  I challenge
anyone who thinks things can be removed to roll up their sleeves and make
a good case for it.  I'd be happy to have something easier to read.

mcl


More information about the freebsd-ports mailing list