Date: Sun, 27 May 2007 20:44:56 -0500 From: linimon@lonesome.com (Mark Linimon) To: Michel Talon <talon@lpthe.jussieu.fr> Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Looking for speed increases in "make index" Message-ID: <20070528014456.GA24097@soaustin.net> In-Reply-To: <20070527221528.GA19603@lpthe.jussieu.fr> References: <20070527221528.GA19603@lpthe.jussieu.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070528014456.GA24097>