Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Aug 2006 20:06:34 +0200 (CEST)
From:      Oliver Fromme <olli@lurza.secnetix.de>
To:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: make(1) is broken?
Message-ID:  <200608101806.k7AI6Y00089040@lurza.secnetix.de>
In-Reply-To: <20060810211333.2d0a73fe@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <wink>.
        -- Tim Peters



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608101806.k7AI6Y00089040>