Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
MIME-Version:	1.0
Message-ID:	<16518.52678.231852.814060@lemming.engeast.baynetworks.com>
Date:	Wed, 21 Apr 2004 15:38:46 -0400
To:	"Dave Korn" <dk AT artimi DOT com>
Cc:	<cygwin AT cygwin DOT com>, <bug-make AT gnu DOT org>
Subject:	RE: Cygwin make thinks a statement can be neither true nor false....
In-Reply-To:	<NUTMEGbpEkiUaUFNjby0000055d@NUTMEG.CAM.ARTIMI.COM>
References:	<16517 DOT 28015 DOT 712309 DOT 634072 AT lemming DOT engeast DOT baynetworks DOT com> <NUTMEGbpEkiUaUFNjby0000055d AT NUTMEG DOT CAM DOT ARTIMI DOT COM>
From:	"Paul D. Smith" <psmith AT gnu DOT org>
Reply-To:	"Paul D. Smith" <psmith AT gnu DOT org>
Organization:	GNU's Not Unix!

%% "Dave Korn" <dk AT artimi DOT com> writes:

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

--warn-undefined-variables already only warns about truly undefined
variables.  It won't warn about variables which are defined but empty.

  >> As gross as the syntax is, the make parser has to be equally quirky in
  >> order to handle it :-/.

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

The thing about make grammar is that is not in any way LALR.  In fact,
make syntax is really a few completely different "languages" in
different contexts, each with their own unique set of semantic, and even
lexical!, rules.

Writing a parser for it would be interesting, but I suspect it would be
a _LOT_ of work, and would need to use a lot of special features of
whatever LR tool you chose.  Something like PCCTS might be better suited :).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith AT gnu DOT org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

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

- Raw text -