From owner-freebsd-ports Tue Jun 29 19: 3:20 1999 Delivered-To: freebsd-ports@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 74E6314E39 for ; Tue, 29 Jun 1999 19:03:13 -0700 (PDT) (envelope-from vanderh@ecf.toronto.edu) Received: from localhost.nowhere (ppp1652.on.bellglobal.com [206.172.249.116]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id WAA20117; Tue, 29 Jun 1999 22:06:14 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id VAA52975; Tue, 29 Jun 1999 21:36:04 -0400 (EDT) (envelope-from tim) Date: Tue, 29 Jun 1999 21:36:03 -0400 From: Tim Vanderhoek To: Steve Price Cc: Mikhail Teterin , ports@FreeBSD.ORG Subject: Re: tcl81 port takes forever to START building Message-ID: <19990629213603.A49201@mad> References: <199906291908.PAA74662@misha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Steve Price on Tue, Jun 29, 1999 at 07:43:04PM -0500 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 29, 1999 at 07:43:04PM -0500, Steve Price wrote: > This is because of all the MLINKS in the Makefile. Care to > take a stab at making the MLINKS code in bsd.port.mk faster? There's more to it than this. Look, bash-2.02# time make generate-plist ===> Generating temporary packing list real 0m41.125s user 0m38.757s sys 0m1.996s bash-2.02# USE_X_PREFIX=t time make generate-plist ===> Generating temporary packing list 4.15 real 2.18 user 1.92 sys bash-2.02# /usr/bin/time make generate-plist ===> Generating temporary packing list 41.06 real 38.79 user 1.95 sys There's a bug somewhere that's rearing a very ugly head. It seems to vary from computer to computer... Anyways, with regards to optimizing bsd.port.mk.... Satoshi has been bugging me about INDEX generation for the last week or so... :-) Currently I have patches that changes the time required for a "make index" done in the ports/astro directory on my computer from 35s to under 10s. Not all of those optimizations apply outside of INDEX generation, however. Improving the time required to handle MLINKS is very difficult, without optimizing more(1) itself (although it has a lot of room for improvement). It would actually be fairly straightforward if we (I) had chosen different semantics for MLINKS ... require a different MLINKS variable for each manpage section. For anyone who really wants to try optimizing this, the trick is will involve this little piece of code... _MLINKS+= ${MAN${__sect:S/l/L/:S/n/N/}PREFIX} ... You have to think of some way of putting the correct MAN[1-9LN]PREFIX in front of each entry in MLINKS _without_ using a make .for ... .endfor loop. FWIW, I do have some vague ideas on how this could be possible, but I haven't even concretely figured-out what I'm thinking, let alone done a proof-of-concept or implementation. Not only that, but they're very evil ideas, and yet, they have this strange attraction... :-) Hmm... They're starting to solidify even as I finish this para... Alternatively, you optimize make's handling of .for loops, and possibly some specific parts of its handling of variable look-ups (currently uses a simple linked-list). -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message