From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 10 18:06:44 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 818FB16A4DA for ; Thu, 10 Aug 2006 18:06:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id F059543D5E for ; Thu, 10 Aug 2006 18:06:41 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (klyvwf@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k7AI6Yf6089041 for ; Thu, 10 Aug 2006 20:06:40 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k7AI6Y00089040; Thu, 10 Aug 2006 20:06:34 +0200 (CEST) (envelope-from olli) Date: Thu, 10 Aug 2006 20:06:34 +0200 (CEST) Message-Id: <200608101806.k7AI6Y00089040@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20060810211333.2d0a73fe@localhost> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 10 Aug 2006 20:06:40 +0200 (CEST) X-Mailman-Approved-At: Thu, 10 Aug 2006 18:37:29 +0000 Cc: Subject: Re: make(1) is broken? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2006 18:06:44 -0000 Stanislav Sedov wrote: > Oliver Fromme wrote: > > I think it is better not to rely on that side effect. It > > isn't well documented and might change without notice in > > the future. > > Thanks for explanation. I suppose, however, that .for behavior could > be used rather safely for it's well documented in make(1). I wouldn't call that side-effect "well-documented". The manpage says: | The iteration variable is successively set to each | word, and substituted in the make-rules inside the | body of the for loop. While that description is correct, it doesn't clearly state the side-effect of allowing nested expansion of the loop variable within other variables, i.e. the fact that a line VAR=${foo:M${bar}} is parsed and handled completely differently, depending on whether "bar" is a loop variable or a normal variable. Well, if you like it, you're free to use that hack to wrap your nested variable expansion in a dummy for loop. But don't complain if it doesn't work anymore in FreeBSD 8. :-) > According > to this manpage, it's not a side effect - .for loops always unrolled > and variable substitutions occurs. Yes, but the point is that _nested_ variable substitutions (inside other variables) are only documented to work for the ":S" modifier, but nowhere else. Relying on something that's not documented is asking for trouble. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters