Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Dave Korn" To: Cc: Subject: RE: Cygwin make thinks a statement can be neither true nor false.... Date: Tue, 20 Apr 2004 12:52:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20040420014032.061F1A8670@perpugilliam.csclub.uwaterloo.ca> Message-ID: X-OriginalArrivalTime: 20 Apr 2004 11:52:35.0953 (UTC) FILETIME=[F8EB2E10:01C426CD] > -----Original Message----- > From: cygwin-owner On Behalf Of Ross Ridge > Sent: 20 April 2004 02:41 [ Cc'd to the gmake bug reporting list; the actual bug report is at the end of this post, and is not what the topic of this thread was originally about. ] > > Possibly a bug in make, as I'd expect it to complain > >about an undefined function named "error:". > > I would've expected it to complain about a bad substition reference, > ie. it's missing an "=". Or at least do anything, rather than nothing! > > Similar constructs are also silently ignored: > > > > $(foo This isn't a valid make function) > > $(bar Neither is this) > > Since "foo" and "bar" aren't functions supported by GNU Make these are > just simple variable references. Eg: > > foo This isn't a valid make function=one > bar Neither is this=two > > test: > echo $(foo This isn't a valid make function) > echo $(bar Neither is this) Eeeurgh. It even warns about this kind of nonsense in 'info make': ------->snip!<------- A variable name may be any sequence of characters not containing `:', `#', `=', or leading or trailing whitespace. However, variable names containing characters other than letters, numbers, and underscores should be avoided, as they may be given special meanings in the future, and with some shells they cannot be passed through the environment to a sub-`make' (*note Communicating Variables to a Sub-`make': Variables/Recursion.). ------->snip!<------- Great. So for the benefit of providing a feature that is virtually impossible to safely and correctly use (chars in variable names that aren't allowed in shell variables) the authors of make have created a syntax that is so ambiguous it defies error detection and reporting. Wahey. Considering the close conceptual relationship between shell variables and make variables, and the way they get exported and imported to each other, it just seems like a mistake to try and pretend they're decoupled to such an extent they could be incompatibly named. Anyway, I've found what seems to be a real bug in make (or perhaps in the make docs): here's a quote from the item "Communicating Options to a Sub-`make'" (under "Node: Options/Recursion") in 'info make' ------->snip!<------- Likewise variables defined on the command line are passed to the sub-`make' through `MAKEFLAGS'. Words in the value of `MAKEFLAGS' that contain `=', `make' treats as variable definitions just as if they appeared on the command line. *Note Overriding Variables: Overriding. ------->snip!<------- Oh no it doesn't: neither for variables defined on the initial make command line, nor for variables passed to a recursive submake. Here's my sample makefile: ------->snip!<------- $(warning : MAKEFLAGS are $(MAKEFLAGS)) $(warning : MAKEOVERRIDES are $(MAKEOVERRIDES)) .PHONY: all silly force all: $(MAKE) silly FOO=1 BAR=2 BAZ=3 $(MAKE) silly BILL=1 BEN=2 silly: force echo Make silly..... force: ; echo force ------->snip!<------- and here's what happens when I test it: ------->snip!<------- dk AT mace /davek/test/mk-test/test3> ls -al total 1 drwxr-xr-x+ 2 dk Domain U 0 Apr 20 12:40 . drwxr-xr-x+ 5 dk Domain U 0 Apr 20 12:40 .. -rw-r--r-- 1 dk Domain U 240 Apr 20 12:47 makefile dk AT mace /davek/test/mk-test/test3> make makefile:2: : MAKEFLAGS are --unix makefile:3: : MAKEOVERRIDES are make silly FOO=1 BAR=2 BAZ=3 make[1]: Entering directory `/davek/test/mk-test/test3' makefile:2: : MAKEFLAGS are --unix -w makefile:3: : MAKEOVERRIDES are BAZ=3 BAR=2 FOO=1 echo force force echo Make silly..... Make silly..... make[1]: Leaving directory `/davek/test/mk-test/test3' make silly BILL=1 BEN=2 make[1]: Entering directory `/davek/test/mk-test/test3' makefile:2: : MAKEFLAGS are --unix -w makefile:3: : MAKEOVERRIDES are BEN=2 BILL=1 echo force force echo Make silly..... Make silly..... make[1]: Leaving directory `/davek/test/mk-test/test3' dk AT mace /davek/test/mk-test/test3> make DOES_IT_WORK=NO_NOT_AT_ALL makefile:2: : MAKEFLAGS are --unix makefile:3: : MAKEOVERRIDES are DOES_IT_WORK=NO_NOT_AT_ALL make silly FOO=1 BAR=2 BAZ=3 make[1]: Entering directory `/davek/test/mk-test/test3' makefile:2: : MAKEFLAGS are --unix -w makefile:3: : MAKEOVERRIDES are BAZ=3 BAR=2 FOO=1 DOES_IT_WORK=NO_NOT_AT_ALL echo force force echo Make silly..... Make silly..... make[1]: Leaving directory `/davek/test/mk-test/test3' make silly BILL=1 BEN=2 make[1]: Entering directory `/davek/test/mk-test/test3' makefile:2: : MAKEFLAGS are --unix -w makefile:3: : MAKEOVERRIDES are BEN=2 BILL=1 DOES_IT_WORK=NO_NOT_AT_ALL echo force force echo Make silly..... Make silly..... make[1]: Leaving directory `/davek/test/mk-test/test3' dk AT mace /davek/test/mk-test/test3> ------->snip!<------- As you can see, they still end up in $MAKEOVERRIDES, so there's a simple and practical workaround, but either the docs or the program behaviour are wrong. cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/