From owner-freebsd-hackers@FreeBSD.ORG Mon May 28 02:15:42 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01D3616A468 for ; Mon, 28 May 2007 02:15:42 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DC6D713C458 for ; Mon, 28 May 2007 02:15:41 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id ED99FAC3; Sun, 27 May 2007 20:44:56 -0500 (CDT) Date: Sun, 27 May 2007 20:44:56 -0500 To: Michel Talon Message-ID: <20070528014456.GA24097@soaustin.net> References: <20070527221528.GA19603@lpthe.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070527221528.GA19603@lpthe.jussieu.fr> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Mon, 28 May 2007 02:36:45 +0000 Cc: ports@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Looking for speed increases in "make index" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2007 02:15:42 -0000 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