Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Wed, 7 Feb 2001 13:24:08 +0000 (GMT Standard Time) From: Robert Bogomip To: Scott Carter cc: Subject: RE: make 3.79: core dump expanding target specific variables In-Reply-To: Message-ID: X-X-Sender: iestyn AT blade DOT ox DOT mathengine DOT com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Feb 2001, Scott Carter wrote: > > I don't have a explanation/solution for the core dump, but here's a > explanation of why you get [ 2] rather than [2] > > http://sources.redhat.com/ml/cygwin/2000-07/msg00816.html > (summary: += inserts a space.) > No, I don't think so when this is the first time the variable is defined. If we use the original Makefile without the target specific variables we have: t+=2 t: @echo "[${t}]" giving: $ make all [2] $ on all versions of make I have (3.77, 3.78, 3.79 on Linux & cygwin). The docs say "objects += another.o This takes the value of the variable objects, and adds the text `another.o' to it (preceded by a single space)." and a little further down, "When the variable in question has not been defined before, `+=' acts just like normal `=': it defines a recursively-expanded variable." A little ambiguous, but the tests above confirm that a space is only inserted if ${t} already exists (even if it is empty). BTW, the original core dump occurs on Linux make 3.79 too, so I suppose it's a real make bug. -- Robert Bogomip /// mailto:bob DOT bogo AT milohedge DOT com Milo Hedge Ltd, OCFI, Mill Street, Oxford, OX2 0JX /// tel:+44 1865 799400 -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple