From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 06:54:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4978B16A4CE; Thu, 5 Feb 2004 06:54:20 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77EB043D58; Thu, 5 Feb 2004 06:54:18 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i15EsInJ026437; Thu, 5 Feb 2004 07:54:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 05 Feb 2004 07:54:06 -0700 (MST) Message-Id: <20040205.075406.94840701.imp@bsdimp.com> To: bde@zeta.org.au From: "M. Warner Losh" In-Reply-To: <20040206012805.N8113@gamplex.bde.org> References: <20040205091634.GC13932@FreeBSD.org.ua> <20040206012805.N8113@gamplex.bde.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: jmallett@FreeBSD.org cc: ru@FreeBSD.org cc: current@FreeBSD.org cc: bde@FreeBSD.org Subject: Re: Very long SRCS list with unusually long src/ prefix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 14:54:20 -0000 In message: <20040206012805.N8113@gamplex.bde.org> Bruce Evans writes: : This seems to run echo once for each file separately. It should be deemed : inefficient :-). When Timing Solutions hit the problem, we tried a lot of different things and found that this was the only one that would actually work. We tried a whole lot of different ways to do this, and all of them were found wanting. The hard part was getting things passed to the shell in small enough chunks to be useful. If something better can be done, I'd love to hear it. : I can't see anything better using current make features. The make -V hack : doesn't work with local variables. True. We hit that right away. That was one of the clever hacks that we thought about. : This and some other things would be easier and more efficient if make : had a builtin echo. Then we could just use "builtin_echo ${.ALLSRC:M*.[cS]} : | mkdep ..." in the rules below, and the make -V hack would not be needed : in kern.post.mk. That would be cool. We'd tried to come up with a patch that didn't require hacks to make. One could also have a builtin xargs as well that would someway deal with dicing and slicing things up into the right-sized chunks. We discussed adding calls to realpath, which in our case would have shortened the strings just enough to make it work w/o xargs, but that was also rejected because each additional character of the base path length added like 500 characters to the libc mkdep command line. We also thought about just raising the limit in the kernel, but quickly discovered that they were small to make exec more efficient. : % ${DEPENDFILE}: ${DPSRCS} : % rm -f ${DEPENDFILE} : % .if !empty(DPSRCS:M*.[cS]) : % - ${MKDEPCMD} -f ${DEPENDFILE} -a ${MKDEP} \ : % - ${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BID]*} \ : % - ${.ALLSRC:M*.[cS]} : % + (cd ${.CURDIR}; ${MAKE} _mkdep_cS) | xargs env \ : % + ${MKDEPCMD} -f ${DEPENDFILE} -a ${MKDEP} \ : % + ${CFLAGS:M-nostdinc*} ${CFLAGS:M-[BID]*} : : make uses a real shell, so the env shouldn't be needed. The problem is that the expansion of MKDEPCMD. It may expand to "FOO=bar mkdepcmd" so the xargs doesn't do the right thing; It tries to exec FOO=bar. The env is needed so that it will properly expand things in that case. We hit this early in our attempts at Timing Solutions to come up with a good fix lead to tossing an 'env' in there. Warner