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: , Subject: RE: Cygwin make thinks a statement can be neither true nor false.... Date: Wed, 21 Apr 2004 19:53:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <16517.28015.712309.634072@lemming.engeast.baynetworks.com> Message-ID: X-OriginalArrivalTime: 21 Apr 2004 18:53:02.0015 (UTC) FILETIME=[DF3C84F0:01C427D1] > -----Original Message----- > From: Paul Smith On Behalf Of Paul D. Smith > Sent: 20 April 2004 19:35 > To: Dave Korn > %% "Dave Korn" 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/