[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul D. Smith
Subject: RE: Cygwin make thinks a statement can be neither true nor false....
Date: Tue, 20 Apr 2004 14:35:27 -0400

%% "Dave Korn" <address@hidden> writes:

  dk> [ This is getting off topic for the cygwin list, and unless I've
  dk> managed to spot any *real* bugs yet, it's not very OT for the
  dk> bug-make list either; if we want to carry on further we should
  dk> perhaps take it to private mail or to the help-make list, though
  dk> I'm not subbed to any of the make lists.  ]

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

I know you're not subscribed, Dave; I keep having to approve your posts
by hand :).

  >> If you enable --warn-undefined-variables then you'll get a warning.

  dk> Ah, thanks!  That's such a good option I think I'm about to alias
  dk> it right into all my make commands.

The problem is that in many makefiles you tend to get a lot of "false

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! :).

  dk> I mean, look at this: (I'm not going to call it a bug _just_ yet,
  dk> because things that seem utterly unreasonable to me *keep* on
  dk> turning out to be the expected and desired behaviour!)

  dk> ifne ($(VARIABLE), anything)

So, this is a syntax error: it should be "ifneq".

Any invocation of this makefile will fail immediately:

  dk> address@hidden /davek/test/mk-test/test5> make -f makefile1
  dk> makefile1:2: one one
  dk> makefile1:3: *** missing separator.  Stop.

Like this.

  dk> Now where's the sense in that?  How can it be that the semantics
  dk> of the conditional operator affects the validity of the
  dk> otherwise-identical syntax?

Don't quite understand this question...?

  dk> Every time make gives me that same old error message, I just want
  dk> to scream at it


Yeah.  The problem, as you correctly pointed out earlier, is that make's
syntax is so loose that there's virtually no useful checking that can be

This error, "missing separator", is basically make's way of saying
"Syntax Error", or in other words... "Say what?"

Make parses makefiles line-by-line, and it categorizes each line as one
of three things (four things for GNU make): either a variable setting,
or a target definition, or a command script.  In GNU make there are also
preprocessor statements like ifeq, include, export, etc.

Make tells the difference between the three main types of line
definition by looking for the "separator"; the first unique thing in the
line that it can use to make that distinction.

If the first character is a TAB (considered a "separator" I guess), then
it's a command script line as long as there is some target definition
"active" on which to hang the script line.  If not, it looks at the line
further to see if it's one of the other types.

If the separator is "=" or ":=" or "+=" or "?=" (as long as it comes
after one word), then the line is considered to be a variable definition
and parsed that way.

If the separator is ":" or "::", then the line is considered to be a
target and parsed that way.

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?"

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

 Paul D. Smith <address@hidden>          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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]