%% "Dave Korn" <[EMAIL PROTECTED]> 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 like. 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 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! :). 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> [EMAIL PROTECTED] /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 dk> " WHAT THE HELL KIND OF SEPARATOR ARE YOU EVEN TALKING ABOUT, YOU dk> DELUSIONAL MANIAC? " 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 done. 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 <[EMAIL PROTECTED]> 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/