From owner-freebsd-ports@FreeBSD.ORG Mon May 28 01:47:24 2007 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 590FB16A400; Mon, 28 May 2007 01:47:24 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1049C13C455; Mon, 28 May 2007 01:47:23 +0000 (UTC) (envelope-from stephen@math.missouri.edu) Received: from laptop2.montlan (12-216-253-187.client.mchsi.com[12.216.253.187]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20070528014722m9200d9nk8e>; Mon, 28 May 2007 01:47:23 +0000 Message-ID: <465A34AA.8000002@math.missouri.edu> Date: Sun, 27 May 2007 20:47:22 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.2) Gecko/20070525 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Bakul Shah References: <20070527231254.D0C325B5E@mail.bitblocks.com> In-Reply-To: <20070527231254.D0C325B5E@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, hackers@freebsd.org Subject: Re: Looking for speed increases in "make index" and pkg_version for ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2007 01:47:24 -0000 I'm looking for something that will work with the existing framework. But yes, I get the feeling that maybe using "make" to process the ports might be the source of the problem. Make is a program primarily designed for figuring out which was made first, the target or the source, but in the ports what we really want is a scripting language that presides over "cd WKSRC; make". (P.S. sorry for top-posting, but I am following your lead.) Bakul Shah wrote: > Not quite what you asked for but... > > Given the size and complexity of the port system I have long > felt that rather than do everything via more and more complex > Mk/*.mk what is is needed is a ports server and a thin CLI > frontend to it. > > This server can store dependency data in an efficient manner, > deal with conditional dependencies, port renames, security > and what not. It can build or fetch or serve packages, > handle updates etc. Things mentioned in UPDATING file can > instead be done by the server. In general it can automate a > lot of stuff, remove error prone redundancies etc. If it is > small enough and written in C, it can even be shipped with > the base system instead of various pkg_* programs. > > It can provide two interfaces, one for normal users (with > commands like add, check, config, delete, info, search, > update, which) and one for port developers (command for > adding/remove/renaming ports, etc.). Initially it must work > with existing Makefiles. > >> I have been thinking a lot about looking for speed increases for "make >> index" and pkg_version and things like that. So for example, in >> pkg_version, it calls "make -V PKGNAME" for every installed package. >> Now "make -V PKGNAME" should be a speedy operation, but the make has to >> load in and analyze bsd.port.mk, a quite complicated file with about >> 200,000 characters in it, when all it is needing to do is to figure out >> the value of the variable PKGNAME. >> >> I suggest rewriting "make" so that variables are only evaluated on a >> "need to know" basis. So, for example, if all we need to know is >> PKGNAME, there is no need to evaluate, for example, _RUN_LIB_DEPENDS, >> unless the writer of that particular port has done something like having >> PORTNAME depend on the value of _RUN_LIB_DEPENDS. So "make" should >> analyze all the code it is given, and only figure it out if it is needed >> to do so. This would include, for example, figuring out .for and .if >> directives on a need to know basis as well. >> >> I have only poked around a little inside the source for make, but I have >> a sense that this would be a major undertaking. I certainly have not >> thought through what it entails in more than a cursory manner. However >> I am quite excited about the possibility of doing this, albeit I may >> well put off the whole thing for a year or two or even forever depending >> upon other priorities in my life. >> >> However, in the mean time I want to throw this idea out there to get >> some feedback, either of the form of "this won't work," or of the form >> "I will do it," or "I have tried to do this." >> >> Best regards, Stephen >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >