Subject: RE: Cygwin make thinks a statement can be neither true nor false....
From: "Dave Korn" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 20 Apr 2004 12:52:35 +0100

> -----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@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@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@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@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/