RE: Cygwin make thinks a statement can be neither true nor false....

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: Paul Smith On Behalf Of Paul D. Smith
> Sent: 20 April 2004 19:35
> To: Dave Korn

> %% "Dave Korn" <http://cygwin.com/acronyms/#PCYMTNQREAIYR> writes:
> 
>   dk> [ This is getting off topic for the cygwin list, 

> I'll leave it here for now but I'm happy to remove cygwin if 
> folks would  like.

  Nobody's complained yet, but me likewise: if anyone wants this thread off
the cygwin list, just ask.

[ about --warn-undefined-variables ]

> The problem is that in many makefiles you tend to get a lot of "false
> positives".
> 
> For example, many makefiles leave certain variables to be set by the
> user, like CPPFLAGS or CFLAGS.  If you do that in your makefiles, and
> the user has no reason to set them, then you'll get lots o' warnings.
> 
> You can work around this with various GNU make-specific fanciness, but
> most developers don't bother.
> 
>   dk> BTW, did I discuss the difficulty in determining whether a
>   dk> variable is undefined or empty?
> 
> Not with me... to tell the difference you have to use the 
> $(origin ...)
> function and test if the value is "undefined".
> 
> Annoying but... possible! :).

  Hmm.  So might there be call for a variant of --warn-undefined-variables
that only warns about those for which $(origin ..) returns undefined?  That
way makefiles could supply empty-but-overrideable definitions of CFLAGS etc,
and everyone's happy... I think?

>   dk> ifne ($(VARIABLE), anything)
> 
> So, this is a syntax error: it should be "ifneq".

  D'oh and double d'oh!  That has to be the worst cognitive blind spot I've
experienced in years.  I've spent ages and ages reading through the info
docs in the past couple of days and *every*single*time* I've misread the
conditional as ifne rather than ifneq.  Boy, do I look stupid!

> Make parses makefiles line-by-line, and it categorizes each 
> line as one of three things (four things for GNU make): 

[...snip...]

> If none of the above applies (and in GNU make, if it's not a
> preprocessor line), then make doesn't have any idea what the heck the
> line is, so it says:
> 
>     missing separator
> 
> which means, "I couldn't find any of the tokens that allow me 
> to classify
> this line as one of the three (or four) things I know about, 
> so ... eh?"

  BINGO!  The $(SMALL_CURRENCY_UNIT) finally drops!

  I think 90% of the problems I have grokking makefile parsing is that I've
been working on the assumption that it had a full parser, with a lexer and a
stream of tokens and something vaguely bison/yacc like.  For instance, I was
about to ask, given that you can have a colon as a char in a variable name,
how does make know whether VAR:=stuff means to assign 'stuff' to VAR
immediately, or do a deferred assign of 'stuff' to 'VAR:'.  Your explanation
suddenly makes lots of things clear, and I think it should probably be added
to the documentation.  Thank you SO much!

>   dk> I'd just like to point out that it isn't only $shell that is
>   dk> affected: $error and $warning are also affected.  I also notice
>   dk> that it works fine if you escape the semicolon:
> 
> Right.  This is a parser bug, pure and simple.  Except, not so simple
> because the parser has to do the proper matching to realize 
> that the ";"
> is part of a variable or function content.
> 
> As gross as the syntax is, the make parser has to be equally quirky in
> order to handle it :-/.

  Yeh.  I wonder if it would be possible to build a proper parser, using
lexx/yacc/bison/whatever.  But I guess it would be very hard to guarantee
that it behaved in the same way as the original one for backward
compatibility purposes.


    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/